Pre-reconciliation detection

Check each batch before reconciliation starts

• Domain: Finance & Accounting
• Moment: Before the work starts
• Customer: A receivables operation running a daily multi-source reconciliation

Find incomplete and unreliable batches before reconciliation.

The situation

A finance team reconciles incoming payments against invoices and billing notes every day, across two payment flows and twelve source files. The pipeline that does it runs 144 steps. It was built to reconcile, and it reconciles well.

What it was never built to do is check whether the reconciliation should be attempted at all.

What breaks today

Several failure modes can pass without an error.

A required document never arrived. The join runs anyway and produces blanks. The output looks like a result. It is an absence.

A filter empties the sheet. If every payment in a batch has a zero remaining balance, step seven's filter drops every row. The pipeline completes successfully with an empty output that can look like a clean result.

A text field drifts out of format. Three consecutive steps parse a string that is supposed to read "Expected, Actual, Difference". When an upstream system changes that format, all three steps fail silently and carry the failure forward.

None of these throw an error. The operator opens the output, sees a number that looks wrong, and starts hunting. On a 2,144-batch snapshot, 271 batches were missing a required document entirely and 392 were underpaid beyond tolerance. Nobody can hand-check that volume daily, so the checking does not happen and the hunting does.

What Manuel does

Manuel runs five layers of checks before reconciliation starts. Twenty-six named tests run as bulk queries across the full population.

Layer 1, document completeness. Is there a header. Are there line items. Is there a payment. Are the optional documents present or absent, and does their absence matter for this batch type. Six checks. Missing documents block, because there is no arithmetic that fixes an absent file.

Layer 2, structural integrity. Line items whose parent header does not exist in this batch. The same header appearing twice inside one batch. A payment row carrying two batch identifiers at once, which would let it be counted twice downstream. Three checks.

Layer 3, amount balance. The core equation, per flow, with a defined tolerance. Matched within one satang passes. A difference inside the bank-fee band is normal and warns. An overpayment warns, because the excess is handled during reconciliation. An underpayment blocks, because there is not enough money to cover the items and no reconciliation can invent it. Four checks.

Layer 4, header against items. The stored header total is compared with the sum of its lines. Manuel also checks that each line points to a parent document in the same batch. Two checks.

Layer 5, pre-reconcile sanity. Eleven checks that exist purely to catch the silent-empty-output family: every filter in the pipeline that could legitimately drop all rows, every join key that could be null, every degenerate case where the equation balances at zero because no money moved. This is the layer that turns an inexplicable empty result into a named cause.

Every batch resolves to one word: ready, warning, blocked or incomplete. The pipeline reads that word as step zero. It refuses to run on blocked and incomplete, and writes a structured error naming the batches and the reasons. Warning batches proceed with their caveats written into a warnings sheet alongside the output.

The control stops a batch when a check returns an unknown result.

What the customer gets

Document completeness, across the production snapshot of 2,144 batches:

Amount position, across the 2,136 batches included in that breakdown:

In this snapshot, about 55 to 60 percent of batches needed no manual pre-check.

The operator starts with a queue ordered by severity and age. Each item names the reason and identifies any missing file. The queue also shows how long each batch has been waiting.

Every material action retains its actor, its timestamp, its reason, the value before, the value after, and the records it touched. Nothing is physically deleted. Any reconciliation result can be replayed step by step, offline, to show exactly where a number came from.

What stays with your existing systems

The reconciliation pipeline and source systems stay in place. Manuel checks each batch before the existing process runs.

It returns a status and the reasons behind it.

What a first scope looks like

Start with one payment flow and existing source files in read-only mode. We score a historical population and show what the control would have caught before connecting it to the daily process.

Acceptance criteria are measured on your own snapshot.

Related: Residual exception diagnosis / Settlement and fee integrity / Cash-in-bank reconciliation at scale