Specify exactly what is being compared
Begin with a defined population and accounting context. A bank settlement, an invoice register and a general ledger extract can describe related activity at different levels of detail and different stages of completion. State the legal entity, period, account scope, currency basis and inclusion rules for each side. Otherwise a difference may reflect an inconsistent population rather than an actual processing error.
Define the grain of comparison before choosing matching logic. One settlement may cover multiple transactions, while a single invoice may generate several postings. Record whether the control compares transaction records, grouped balances or both. A matching aggregate can conceal offsetting errors, so the level of assurance should be described in terms of the evidence the control actually examines.
Use transparent matching rules
Prefer authoritative transaction references where they exist, but verify their scope and stability. A reference may be unique only within an entity or source system. Build compound identities where necessary and preserve original values. When references are missing, define matching rules using appropriate business attributes and keep their precedence explicit.
Distinguish exact matches, matches within an agreed tolerance and probable matches. A similar amount and nearby date can help identify a candidate but should not silently establish that two transactions are the same. Record the rule that produced each match and require review for ambiguous candidates. Show why records were paired and where several plausible matches remain unresolved.
Treat precision and currency as part of the control
Financial calculations require deliberate numeric representation. PostgreSQL documents exact numeric types and distinguishes them from inexact floating point types. Choose precision and scale appropriate to the amounts and calculations, then define rounding at the correct business boundary. Repeated intermediate rounding can produce a different result from rounding once after an agreed aggregation.
Preserve original currency, converted currency, exchange rate source and the rate’s effective date when comparing converted amounts. A currency difference is not the same thing as a transaction difference. Document permitted tolerances by control and explain whether they apply per item or in aggregate. A broad tolerance can hide a systematic error even when every individual difference appears small.
Keep accounting periods and observation time distinct
Posting date, transaction date, settlement date and ingestion time answer different questions. A payment recorded after a reporting extract may explain a temporary difference without changing the validity of the earlier control. Identify the relevant dates and capture source extract boundaries so reviewers can reconstruct the population used for a particular reconciliation run.
Account for late postings, reversals and reopened periods. Preserve the previous result when rerunning a control after a correction, with a link to the new result and its reason. Avoid updating historical reconciliation evidence in place without a trace. A repeatable control must distinguish what was known when the review occurred from what later source corrections made available.
Give differences an operational lifecycle
Classify exceptions by an actionable cause: missing source record, timing difference, unmatched identity, amount difference or inconsistent currency treatment. Assign the appropriate owner and specify the evidence needed to resolve each category. A generic unmatched status forces reviewers to repeat investigations and makes recurring data problems difficult to distinguish from legitimate timing conditions.
Keep investigation separate from authority to post an adjustment. Record proposals, approvals and the resulting source transaction where an adjustment is required. Ensure a repeated reconciliation run does not create duplicate cases or duplicate adjustment requests. The workflow should preserve the original discrepancy and the reasoning that closed it, including cases where the correct resolution was to accept an explained difference.
Test the control with known discrepancies
Create representative cases involving duplicates, partial settlements, currency conversion, missing records, late postings and offsetting errors. Verify both the matching result and the explanation produced for a reviewer. Test the effect of a source schema change and a partially completed extract. A reconciliation that reports success on incomplete input can create more risk than one that visibly fails.
Retain source references, rule versions, run identity and approval evidence according to the organisation’s requirements. OpenLineage and W3C PROV provide concepts for describing execution and derivation. Responsible finance professionals should review the control design and verify that they can reproduce its results, investigate differences and trace each resolution to an approval.