How to manage reconciliation exceptions month after month

Two teams resolve the same retailer discrepancy every month: someone opens an email thread, both sides agree to carry the amount forward, and the item vanishes until the next close brings it back. That is not exception management; it is rediscovery. An exception becomes manageable when it carries a record, a category, an owner, a status, evidence and an aging rule, and when it survives contact with the next month.

This guide shows how to build that operating loop: define the exception record, separate causes from symptoms, assign one owner, move each item through a visible status lifecycle, and let aging, recurrence and reporting tell you when a monthly fix has become a process gap.

Define the exception record

A reconciliation exception is one difference that fails the equation at a stated grain and tolerance. Give it a record that stands alone, without needing the original conversation to understand it. The record carries the source files, the grain (product, store, period), the amount and direction, the first and last month seen, the category, the owner, the status, the evidence and the next action.

If someone new cannot read the record in five minutes, the exception is not managed; it is documented. The record is also the unit of measurement: exception counts, aging and recurrence are all computed from fields the record owns.

A taxonomy that separates cause from symptom

Classify each exception by cause, not by appearance. Two rows can both be unmatched and need different treatments: one is an identifier gap waiting in the master-data queue, the other is a duplicate delivery that must be quarantined. A cause-based taxonomy keeps the same symptom from being resolved in five different ways.

1. Timing or carry-forward differences that should clear in the next period.
2. Missing movements with a known source, such as returns, transfers or damages.
3. Identifier gaps where a product or store does not map.
4. Genuine stock or sales variance without a document, such as shrinkage.
5. Source-quality issues such as duplicate deliveries, wrong units or late files.

One owner and a visible status lifecycle

Assign each exception a single owner. Multiple owners create the monthly email thread you are trying to remove. The record moves through a fixed status lifecycle: new, triaged, in progress, carried forward, resolved or rejected. Every transition requires evidence; a status change without evidence is not a decision.

Carried forward is a legitimate status, not a failure. It means the item was reviewed, a calendar or timing reason was recorded and the amount is expected to clear. The status stops being legitimate when it repeats without new evidence.

Aging and materiality decide who reviews

Track how long each exception has been open and its size. Aging and materiality are the two fields that make a queue manageable. Small and old matters more than large and new: an item open for six months signals a process gap even when the amount is modest. The register below shows the shape a queue takes.

Two items belong to the same category and the same owner, which tells you the mapping table is the problem. One item is quarantined with a source-quality cause and another sits open with no movement hypothesis. The register makes the next review a decision, not a search.

Recurrence is the signal for a process fix

When the same category reappears in the same form, the exception is a symptom. A monthly queue should not only resolve items; it should feed a small fix backlog. Add the category to a fix review when it recurs twice in a rolling three months, and move the fix owner in when it recurs three times.

Recurrence is measured by category, not by item. A new SKU that fails the mapping check twice is the same failure happening twice. The category, not the product, is what needs the fix.

Evidence that travels with the record

Every decision on an exception needs evidence attached at the moment it happens: the source file, the row, the calculation, the carry-forward note. Evidence needs a date and a version. An exception whose evidence is reconstructed at year-end is a number, not an audit trail.

Keep evidence on the record rather than in a folder. If the evidence lives only in an analyst's inbox or a shared drive, the record cannot be reviewed, aged or handed over. The record is only as useful as the evidence attached to it.

Reporting that closes the loop

At each close, publish a short exception report: count and value by category, by owner and by status, with aging. The report is the decision record for the month. It answers three questions: what was added, what cleared and what aged.

One page is enough. If the report needs interpretation by the person who wrote it, the record is failing. The report should let a reader see the shift from the previous month at a glance: same categories, same owners, aging down.

Practical takeaway

Manage reconciliation exceptions with a record, a cause-based category, one owner, a visible status lifecycle and evidence on every item. Let aging drive review and let recurrence feed a fix backlog. The monthly exception report becomes the decision record, and the queue stops being rediscovered.

Marksyte's data reconciliation and controls service and managed data operations can design the exception record, the taxonomy, the status lifecycle and the monthly reporting for retailer and distributor reconciliation.

Frequently asked questions