Spring Batch reconciliation: report accepted and rejected receipt IDs

Last updated: 1 Oct 20264 min read

tutorial

A job result needs business counts and source identities alongside its framework status when skips are permitted.

Define the accounting equation

For a fixed manifest, record each unique source receipt ID and one terminal decision: accepted, rejected for review, or unprocessed after failure. A count alone cannot reveal whether a source row was read twice after restart. The local skip test proves a three-row target and one skip, and the listener test stores one rejected ID and reason. Neither stores the full per-manifest decision ledger.

Keep failure from masquerading as success

If a failed job committed ID 1 before a later bad row exceeded the budget, the report must say partial. A rerun with the same manifest may revisit data. Key the reconciliation rows by manifest plus source ID, then compare content fingerprints before accepting another decision. Job identity determines which execution history the operator is reviewing.

Limit sensitive retention

Record a concise error code and source locator rather than copying an entire private row into logs. Set retention and access controls for correction queues. An audited correction is a new business decision, not a silent mutation of the original accepted row.

Boundary sketch

record ImportDecision(String manifestId, String receiptId,
    String state, String payloadHash, String reasonCode) {}

Cost and verification

A durable decision row adds one keyed write per source record and a review workflow. Hashes detect changed replay only when input normalization is stable. This design remains unexecuted in the source kit.

Common Mistakes

Do not infer accepted count by subtracting skip count after a failed job.
Do not log full private receipt payloads as a substitute for a correction queue.
Do not mark skipped financial work completed without review.