Why retailer and ERP sales land in different periods

A retailer reports the last week of the month on Sunday evening. The ERP posts invoices on the last calendar day, and some deliveries are invoiced days after the goods arrive. One transaction near the boundary appears in the retailer's July file and the ERP's August extract. Both systems are correct; the periods are simply not aligned.

Timing differences are the most common and least understood cause of retailer-to-ERP variance. They reverse in a later period, so they never appear in annual totals, but they create month-end noise that distracts from real issues. This guide explains the dates each system uses, shows a boundary example and identifies the evidence needed before a variance is treated as a timing issue.

This page is the diagnostic starting point: it explains why correct retailer and ERP transactions can land in different periods. For the reusable date-to-period bridge and 4-5-4 calendar rules, continue to retail and financial calendar reconciliation.

The dates each system uses

Retailer sell-out is reported on a retail calendar: typically a Monday-to-Sunday week that closes and is delivered shortly after the period ends. The ERP records commercial documents with several dates, including the order date, the delivery date, the invoice date and the posting date. Each date describes a different moment, and the posting date usually determines the period in which a document appears in the ERP extract.

Write down for each source which date defines the period. Without that, a document near the boundary looks like a genuine variance instead of a calendar effect.

A boundary example

Suppose a delivery is invoiced on the last day of August but received by the retailer in the first week of September. The retailer's sell-out week W35 closes on 2 September, while the ERP August extract includes the invoice because its posting date is 31 August. Same goods, two periods, both correct.

The 120 units appear in different periods in each system. The exception is carried forward, and the next retail week should show the sell-out of those units so the variance clears. If it does not clear, the cause is not the cutoff and the exception stays open for investigation.

Build a calendar bridge

A calendar bridge is a lookup that maps every date to the retail week and the financial period it belongs to. It handles week starts, 4-4-5 calendars, 53-week years and partial periods. Both sources use the same bridge, so a date resolves to exactly one period in each calendar.

Build the bridge as a table with an effective date and an owner, not as a formula hidden in a workbook. The same rule must apply to every retailer, every month, or the bridge itself becomes a new source of variance.

Carry-forward rules

When a timing difference is confirmed, the exception should not be adjusted in place. It is carried forward: the amount, the source, the document reference and the expected clearing period are recorded, and the next cycle checks that the quantity reversed. A timing exception is closed only when the carry-forward clears, not when it is posted away.

Evidence for a timing difference

The evidence for a timing difference is the document that crosses the boundary: the invoice, the delivery note or the shipment record with its date. Keep the reference on the exception so the next cycle can match it. Without a document reference, "timing" becomes a label that covers any unexplained difference.

Common mistakes

• Adjusting the number in place instead of carrying the exception forward. This hides the reversal and doubles the variance when the quantity later clears.
• Using different week or month definitions for the same retailer in different months. The bridge must be one versioned table.
• Treating a carry-forward exception as closed without checking the next period. A timing difference is closed only when it clears.
• Blaming the retailer for a difference the calendar explains. Check the boundary documents before escalating.
• Building a new bridge rule every month. That converts a controlled lookup into a maintenance habit.
• Forgetting the 53rd week in annual reconciliations. Some retail calendars add a week, and the totals never align without it.

Practical takeaway

To reconcile retailer and ERP periods, write down the date each system uses, test the transactions near the boundary, build one calendar bridge used by every source, carry timing exceptions forward with evidence, and close them only when the next period clears them. Timing differences then become explained movement instead of monthly noise.

If period-end variances keep reversing every month, Marksyte's data reconciliation and controls service can design the calendar bridge, the carry-forward rules and the exception controls that turn them into traceable, explained movement.

Frequently asked questions