A retailer files 40 units returned to the supplier, the ERP shows a credit note for 55 and the sell-out file carries a negative line for 12. All three are returns of a kind, and each reconciles differently. Returns become a recurring source of false variances when consumer returns, stock returns, credit notes and restatements are treated as one thing.
This guide separates the types of return, maps the event timeline behind each one, defines the matching logic, handles restated files and closes with exception categories and controls.
The types of return
Four different events carry the label "returns". Consumer returns are product a shopper brings back to the store and appear as negative sell-out in the POS. Stock returns to the supplier appear in return shipments and credit notes in the ERP. Trade returns are unsold stock returned under an agreement. Credits and restatements adjust a file or an account and may move no product at all.
Each type has its own event, its own sign and its own source. Write down the type before comparing numbers. If the comparison treats a credit note as a consumer return, the bridge will produce a variance that no matching logic can explain.
The event timeline
A return has several dates: the shopper's return date, the store's stock-in date, the return-to-supplier date and the credit note date. Each system records a different one. POS records the shopper's return; the ERP records the credit note. Compare event dates, not invoice dates, and state which date each source carries.
The event timeline is what turns a return into a reconcileable position. If the return is booked in the retailer's week and the credit note in the supplier's month, carry the difference forward and expect it to clear in the following period.
Matching logic
Match by type and by grain. Consumer returns match to negative POS sell-out at product-store-period. Stock returns match to return shipments and the corresponding credit note at product-retailer-period. Restatements match at the file level, original version against corrected version.
Never match a credit note to a negative sell-out line: they are different events at different grains. Define a key per type, such as retailer code, product and event date, and keep the keys explicit in the mapping table.
Restated files
Retailers restate files, and a corrected file replaces the original for the whole period. Apply the replacement at the file level, keep the original versioned and recompute the affected periods. A restatement is not an adjustment; it is a new version of the same file.
Track the delta between versions and flag which periods changed. Without versioning, a restatement looks like a variance in the period it lands in and silently changes history everywhere else.
A worked example
The table shows one product and one retailer for a month. Each return event reconciles by type, with its own source and matching rule.
| Return event | Source | Amount | Matching rule |
|---|---|---|---|
| Consumer return at the till | POS sell-out, negative line | 12 | Match to negative sell-out, same period and store |
| Stock return to supplier | ERP return shipment | 40 | Match to credit note of 40 |
| Credit note received | ERP credit note | 55 | Split: 40 stock return + 15 trade return |
| Restated sell-out file | Corrected file vs original | 10 | Delta signed off as a new file version |
The negative POS line reconciles to the consumer return, the credit note splits into a stock return and a trade return, and the restatement is carried as a version delta. The variance is explained by naming the event behind each number instead of comparing all of them as one total.
Exception categories
Classify what remains. Timing differences should clear in the next period. Type mismatches appear when a credit note is compared to negative sell-out. Identifier gaps appear when a product or store does not map. Missing documents appear when a stock return has no credit note. Restatement deltas are explained but need sign-off.
Controls
- A fixed taxonomy of return events with their signs and sources.
- Validation that every negative quantity carries a type.
- Total controls per event type before the comparison runs.
- Versioned restated files with changed periods flagged.
- An exception queue with owner, status and evidence on every open difference.
Practical takeaway
Reconcile retailer returns by type, event and sign. Match credit notes to stock returns, negative POS to consumer returns and restatements at the file level. Keep timing explicit and run the difference through the exception queue, and returns stop producing the same false variance every month.
Marksyte's data reconciliation and controls service can design the return-event taxonomy, the matching rules and the controls for retailer and ERP return data.
Frequently asked questions
How do you reconcile retailer returns with ERP data?
By type, event and sign: consumer returns match to negative POS sell-out, stock returns to return shipments and credit notes, and restatements at the file level with the original kept versioned. Timing differences are carried forward with evidence.
Why do consumer returns and ERP credit notes never match?
Because they are different events. A credit note records a stock return or a trade credit; negative sell-out records a shopper's return at the till. They happen at different times and at different grains, so they never reconcile one to one.
What is a restated sell-out file and how do you reconcile it?
A restated file is a new version of the original that replaces it for the whole period. Reconcile it by applying the replacement at the file level, keeping the original versioned, recomputing the affected periods and signing off the delta.