Why retailer sales data does not match your ERP

Retailer sales data does not match the ERP, but nobody can say exactly why. The gap is quoted in meetings as a number, adjusted in a workbook and never resolved. Before anyone changes the number, the difference needs a cause tree: a controlled set of possible explanations and a method for testing each one.

A retailer-to-ERP discrepancy is not an error until the cause is known. It can come from the business event being recorded, the product or location identifier, the reporting period, returns and credits, pack sizes, corrected files or system exports. This guide turns those possibilities into a diagnosis you can run before adjusting anything.

Define the comparison before listing causes

The first step is to state precisely what each number records. Retailer sales data usually means POS or sell-out data: units or value sold to consumers, reported by store and retail period. The ERP typically records commercial documents: orders, shipments, invoices, credit notes and returns, dated by document or posting date. The same word, such as sales, can refer to different events in the two systems.

Write down four things for each source before investigating the gap: the business event, the product identifier and its mapping path, the location grain, and the reporting period or cutoff. If the sources cannot be compared at the same grain and period, the first difference is structural rather than a data error.

Also decide whether you are comparing units, value or both. A gap in units and a gap in value can have different causes, so separate the two comparisons instead of mixing them into one variance.

Ten causes of retailer-to-ERP discrepancies

1. The sources record different business events

Retailer sell-out records consumer demand. An ERP shipment records product leaving your control; an invoice records the commercial obligation. If the comparison mixes sell-out with shipments, inventory still in the retailer network and stock in transit appear as a difference. Confirm that both files describe the same event or accept the event difference as a known bridge.

2. Product identifiers are not mapped

The retailer may report an EAN or its own product code, while the ERP stores an internal SKU. A missing, retired or duplicated mapping leaves valid sales unmatched. Count the unmatched rows and inspect them by product: a handful of unmapped codes can concentrate the entire gap.

3. The location grain does not match

ERP documents may go to a customer account or distribution centre, while sell-out is reported by individual store. A customer can map to many stores. Comparing at the wrong grain turns a legitimate one-to-many relationship into a false discrepancy.

4. Reporting periods and cutoffs differ

A retail week can run Monday to Sunday, while the ERP month closes on the last calendar day and invoices post days after delivery. A transaction near the boundary can appear in a different period in each system without either system being wrong. These differences should clear in a later period when the calendar is bridged correctly.

5. Returns and credits move between periods

Retailer data may be net of consumer returns. The ERP may issue a credit note only when stock is physically returned, sometimes weeks later. Some partners restate earlier sell-out periods; others include adjustments in the current file. Treating every negative quantity as a return can move the discrepancy instead of resolving it.

6. Pack sizes and units of measure differ

One source may report six-packs, another individual units, and a third cases. A case of four six-packs can appear as 4, 24 or 1 depending on the source. Conversion rules must be effective-dated because pack configurations change over time.

7. Corrected files create duplicates or omissions

A retailer that resends a corrected file without versioning can duplicate rows or leave old versions active. An ERP extract that includes cancelled or reversed documents can add phantom quantities. Key uniqueness checks and file versioning catch these before the comparison.

8. Stores or periods are missing or late

A store that has not reported, a period that has not closed or a file received after the comparison cutoff reduces one side of the equation. The gap then looks like a variance when it is actually a coverage problem. Measure coverage by store, product and period before trusting any total.

9. Value, price and currency rules differ

If you compare value, the price basis may differ: retail price, net price, cost, VAT included or excluded. Currency, exchange dates and rounding rules can also diverge. State the value definition for each source and convert both to the same basis before comparing.

10. System exports filter or omit records

An ERP report may exclude certain document statuses, cancelled orders or intercompany movements. A retailer file may exclude self-scan categories or specific banners. Document the filter of every export so the comparison covers the same population.

How to isolate each cause

Run the diagnostic steps in order. Each step removes one family of causes or gives evidence to test it. Stop at the first step that explains the gap, then confirm with the next cycle.

1. Confirm the event. Check the file header and definitions. If sell-out is being compared with shipments, build the stock bridge instead of expecting a direct match.
2. Map product identifiers. Join both files to the product mapping and count unmatched retailer codes and EANs. Review unmatched values for new listings, retired codes and mapping errors.
3. Align the location grain. Aggregate to the level both sources support, such as store, banner or customer. Document any one-to-many location logic.
4. Build a calendar bridge. Map retailer weeks to financial periods and list documents near the cutoff. Timing differences should carry forward and clear.
5. Separate returns and credits. List negative quantities and credit notes by type and period. Apply the agreed returns rule instead of treating all negatives alike.
6. Apply unit conversions. Convert both sources to one unit of measure with effective-dated pack rules, and recompute the comparison.
7. Check for duplicates. Test key uniqueness on the product-location-period grain in both files, and identify corrected resends.
8. Measure coverage. Compare expected versus received stores, products and periods. Quantify missing and late data before interpreting the gap.
9. Compare value rules. If the gap is in value, verify price basis, currency and rounding on both sides.
10. Review export filters. Confirm that both extracts include the same document statuses, banners and channels.

Diagnostic table

What not to adjust

• Changing the retailer's number to make it match the ERP without evidence. This hides the cause and makes the next cycle harder to explain.
• Silently dropping unmapped rows. The matched dataset looks accurate while the hardest records disappear.
• Posting manual adjustments for timing differences that should clear. If the quantity is correct on both sides, a manual entry creates a double count.
• Overriding a mapping to fix one line. A mapping change affects the entire history for that product.
• Closing an exception as “adjusted manually”. That describes the action, not the cause, and the variance will return.
• Trusting a clean total without checking coverage. Missing stores and offsetting products can hide behind a tidy headline.

Escalation path

When the diagnostic steps do not isolate the cause, escalate with evidence rather than with a number. Start with the data team, which owns mappings, source quality, duplicates and coverage. Then involve finance or the control owner for returns, credit notes, cutoffs and materiality. If the evidence points at the source, take the findings to the retailer or distributor relationship owner with a specific request for a corrected file or clarification.

Document every decision, including the evidence, the owner, the status and the follow-up cycle. If the cause is confirmed and cleared, keep the record so the team does not investigate the same issue again.

Practical takeaway

To diagnose why retailer sales data does not match the ERP, start by defining the event, grain, period and value rule for each source. Then work through the ten causes in order, isolating each family with the evidence it needs. Do not adjust a number until the cause is confirmed and documented. Escalate with evidence, and carry unresolved items into the next cycle with an owner and a status.

If your team explains the same retailer-to-ERP differences differently every month, Marksyte's data reconciliation and controls service can review the comparison, the causes and the evidence trail. Related work may include mapping product, customer and store identifiers or standardizing partner files and data-quality rules.

Frequently asked questions