Backdated Documents and Inventory Recosting
A goods receipt dated in the past changes the cost of stock that has already been shipped, invoiced and posted — the hardest problem in inventory accounting.
- Published
- Author
- Konis Software
The goods receipt is dated 3 March. It was entered on 27 March. In between, the stock it covers was picked, shipped, invoiced and posted to the general ledger. None of those documents was created in error — each was correct given the data available at the time. From 27 March, all of them are wrong. This is not an edge case but an ordinary month in any company that moves goods: the supplier is late with paperwork, the customs invoice arrives after the truck, and the freight invoice ten days later is the first moment anyone knows the real landed cost. Inventory is the one area of an ERP where time of entry and time of event routinely diverge — and the only one where that divergence rewrites numbers backwards.
Five dates, not one
The first source of confusion is that the word „date“ has no single meaning in an ERP. A serious document carries at least five, and each drives a different calculation:
- Document date — when the paperwork was drawn up. A formality, but the user sees it first, so it gets confused with the rest.
- Transaction date — when the goods changed hands. It fixes the sequence in inventory and the value of every issue after it.
- Posting date — which accounting period the ledger entry belongs to.
- Tax point date — which VAT period carries the liability or the right to deduct input tax.
- Due date — when the obligation matures. The only one with no bearing on valuation.
„Backdated document“ means exactly one thing: the transaction date is older than the moment of entry. Everything else is consequence. A system with a single date per document does not solve this — it cannot see it, and delegates the difference to an accountant and a month-end spreadsheet.
What actually breaks
Inventory is an append-only stream of movements plus a balance derived from it. While movements arrive in order the model is simple. A late receipt does not append a movement — it inserts one in the middle. And every valuation method is a function of sequence. One item, one warehouse, three documents:
| Document | Transaction date | Entered on | Movement | Unit cost (RSD) |
|---|---|---|---|---|
| PR-2026-00061 | 5 Mar 2026 | 5 Mar 2026 | +200 pcs | 1,100.00 |
| OT-2026-00214 | 12 Mar 2026 | 12 Mar 2026 | −150 pcs | — |
| PR-2026-00087 | 3 Mar 2026 | 27 Mar 2026 | +100 pcs | 1,000.00 |
FIFO
Before the late receipt, FIFO consumed the only available layer for the 150 issued units — 200 pieces at 1,100.00 — giving a cost of goods sold of 165,000.00. After entry an older layer sits in front: 100 pieces at 1,000.00, dated 3 March. FIFO must consume it first, so the same issue now costs 155,000.00. A 10,000.00 swing on a single document. The margin on that invoice was wrong for fifteen days, and nobody made a mistake.
Weighted moving average
Average cost behaves differently and, against intuition, worse. FIFO has layers, so only issues that touched the displaced layer are affected. Average cost has one number, recomputed on every inbound. An inbound on 3 March changes the average from 3 March onward, so every issue after that date takes a different value. Every one, without exception.
| Method | Cost of issue — before | Cost of issue — after | Delta | What else moves |
|---|---|---|---|---|
| FIFO | 165,000.00 | 155,000.00 | −10,000.00 | Issues touching the displaced layer |
| Weighted average | 165,000.00 | 160,000.00 | −5,000.00 | Every issue after 3 Mar — no exceptions |
Under average cost, 160,000.00 is the output of a chain rather than a formula: on 3 March the average becomes 1,000.00; on 5 March an inbound of 220,000.00 lifts the balance to 320,000.00 across 300 pieces, moving the average to 1,066.67; on 12 March 150 pieces leave at that cost. If ten issues follow, all ten shift. If one was a component issued to production, the cost of the finished good shifts too — and so on down the bill of materials. Recosting is not a one-row correction but a wave whose reach is unknowable until computed.
Stock-to-GL reconciliation is a consequence, not a report
In most companies „stock-to-GL reconciliation“ is a spreadsheet exercise at month end: compare the stock ledger valuation against the inventory account balance and hunt for the difference. Once found, it is posted as a manual adjustment with no record of its origin, so next month restarts from zero. Yet the difference is rarely mysterious. It has a finite list of causes, each with a date:
- A late inbound that revalued every issue after its transaction date.
- Landed costs entering valuation after receipt — freight, forwarding and duties from the import declaration arrive with the carrier's invoice, landing on goods already gone.
- A price revaluation posted in a period other than the one in which it changed the value of stock.
- Count shortages and overages posted away from the count date; a shortage against blocked or third-party stock is a separate case with tax consequences.
- A reversal issued after the posting scheme changed — it must use the OLD rule version, or it manufactures the difference it is meant to remove.
- Goods in transit and consignment stock: physically on our floor, legally not ours. If ownership is not a dimension of the model, this gap is permanent.
When the system knows each cause and holds it as a record with a date and a source document, reconciliation stops being an investigation. The report no longer displays a difference — it displays its explanation, line by line, linked to the document that created it.
If a system can compute a difference but cannot explain it, it has not computed the difference — it has relocated the problem to a human.
Recosting is a procedure, not a button
- 1
Establish the point of impact
The movement is inserted at its transaction date, not appended. The point of impact is that date, that item, that warehouse — not the whole ledger, not the whole year. A routine that cannot narrow scope will not run on a real database.
- 2
Identify the affected movements
All movements of the same item after that point, ordered by transaction date, with a deterministic tiebreak — by movement sequence number, never by the time a row reached the database. Without it, two runs over identical data give two results.
- 3
Recompute under the rule in force then
Valuation method, precision and rounding allocation come from the rule version effective on the transaction date, not from current configuration. Switching from average to FIFO in June must not rewrite March.
- 4
Post the delta, not the result
The ledger receives a per-period delta referencing the source document and the recosting run behind it. Overwriting the original posting is not an option: a posted entry is a record, not a variable.
- 5
Leave a trail that survives a question
Every affected issue must answer: what the value was, what it is now, which document caused the change, under which rule version, and who approved it. Recosting without that trail is unprovable — in an audit, indistinguishable from wrong.
| Approach | Behaviour | When it fits | Price |
|---|---|---|---|
| Reject | A document dated into a closed period is refused at entry | Always, for closed periods | Without a „what now“ path, users adjust the date until it is accepted — the problem goes invisible |
| Full recosting | All movements after the point of impact are recomputed; the delta posts to an open period | Open period, serious inventory core | Expensive at volume; needs deterministic ordering and item-level locking during the run |
| Prospective correction | The past is untouched; the difference enters as a revaluation on the day of discovery | Closed period, small delta, long chain of issues | Historical margins stay wrong — deliberately and on the record, not by accident |
| Manual adjustment | An accountant posts the difference by hand so stock and account agree | Never as policy, only as a last resort | The entry has no link to the cause; every later reconciliation restarts from zero |
None of the four is universally right. The right one is chosen deliberately, written down as a rule and applied consistently — not inherited as an accident of a procedure somebody drafted years ago.
The boundary: closed periods and VAT
VAT has its own logic and its own date. The tax point does not automatically follow the movement of goods, the right to deduct attaches to possession of an invoice, and in Serbia the POPDV breakdown and PP PDV return for the prior period are already filed. A late inbound invoice therefore generally belongs in the current filing; the same holds for the EEO and EPP records, whose deadlines carry their own non-working-day shift rules. The asymmetry is worth stating plainly: inventory is recomputed backwards, VAT records are not rewritten. A system tying both to one date will be wrong about one of them.
How NG One approaches this
NG One treats a backdated document as the normal case, not the exception. The warehouse sits in the core — bin locations, directed picking, waves — so the transaction date is not the moment somebody finally reached a keyboard. The rules that make this problem solvable at all were set before the first inventory table was written; rules like these are never added afterwards:
- Five dates on every document as five separate fields — document, transaction, posting, tax point and due date — not a column added later.
- Movements are append-only and the balance derived, with the identity „balance equals the sum of movements“ enforced as a property test over generated scenarios, not one worked example.
- Backdated recosting is an explicit configuration rule, not implicit code behaviour: how far back, under whose approval, with what effect on the ledger.
- Calculation rules — valuation method, precision, rounding allocation, landed-cost distribution — are versioned and effective-dated, so an old calculation reproduces under the old rule.
- The delta reaches the general ledger dimensionally, from the first line: recosting lands on margin by item, warehouse, customer and cost object with no later allocation pass.
- A retroactive goods receipt with part of the stock already sold is an acceptance test, alongside posting into a closed period, reversal after a posting-scheme change, and a count shortage against blocked stock. These are not scenarios tested if time happens to remain.
Backdated documents are not a user error to be trained away. They reflect how goods actually travel and how paperwork actually lags. An ERP that treats them as an exception produces a month-end spreadsheet and an accountant who remembers why last year's difference existed. An ERP that treats them as normal pays up front — in the data model, in versioned rules, and in tests written before the problem occurs. That price is paid once.