A statement file crossing an integration boundary should not immediately create accounting entries. Between receipt and posting sit several different questions: Is the file authentic and complete? Has it been processed before? Which account does it represent? Which open item is the best candidate?
Separate transport, interpretation and accounting
Transport retrieves a file or message. Parsing turns its structure into a stable internal record. Validation determines whether the record is eligible for processing. Matching proposes or confirms a relationship. Posting applies configured accounting treatment. Keeping these concerns separate makes failures diagnosable and replay safer.
Give every input an identity
A retry must not create a second posting. File hashes, statement identifiers, account identifiers and entry references provide layers of duplicate protection. Idempotency belongs at the ingestion and posting boundaries, not only in the user interface.
Model exceptions explicitly
An exception needs a reason code, state, owner and history. “Unmatched” is only one reason: others include ambiguous candidates, balance discontinuity, unsupported transaction codes or a posting rejection. Explicit reasons help finance teams prioritise work and help engineers improve rules without guessing.
Change matching logic safely
Version rules, test them against representative statements and compare proposed outcomes before activation. A change that increases automatic coverage while introducing false positives is not an improvement. Controlled release and observable outcomes are part of the accounting control.