Measuring the value
Never invoice twice: ask the accounting ledger before creating — 199 of 209 invoices were already there
When invoicing moves from the accounting package into the ERP, there is a stretch when both create invoices. If the ERP asks the accounting ledger before it creates one, how many duplicates does a cutover avoid — and what is each duplicate you never clean up worth?
In the weeks invoicing moves into the ERP, how many deliveries are invoiced in both places — and what does cleaning them up cost?
It needs only the invoices the ERP creates a month, the weeks both systems run side by side, and the share the accountant still enters in the accounting package. Everything else follows. Everything is editable.
Derived (whole cutover)
Assumptions — open to see and edit each one
Two books
Time
This is an estimate, not a promise. Set the share still entered in the package to 0, the lookup minutes to 0 and the re-check minutes to 0: every line goes to zero. Revenue counted twice is shown, never added: it is an error to undo, not money earned.
One morning, the machine made an invoice at 7:30 for a supermarket delivery note. That same morning, the accountant had entered that very delivery note into the accounting package as usual. The sync from the accounting package to the ERP runs only at 12:15, so at 7:30 the ERP saw nothing. The result was one delivery note, two invoices, in two sets of books — and neither set is wrong when looked at on its own.
That is nobody's fault. It is the shape of every move of invoicing from the accounting package to an ERP: there is a period when both places invoice, because nobody dares switch off the old place before the new one has run long enough. Measured on a live system, of 209 invoices the machine made for delivery notes in the first two weeks of such a move, 199 invoices — 95% — were already in the accounting package, worth 319 million VND.
This article asks: if, before invoicing, the ERP asks the accounting package's books directly whether the invoice for that PO already exists, how many duplicate invoices does one move avoid, and what is each duplicate that never needs cleaning up worth?
1. What changes
- Ask before invoicing. For each delivery note that is ready, before creating the invoice, the ERP asks the accounting package's books — through a read-only gateway on the accounting machine — whether any sales voucher carries this note's goods receipt number or PO number.
- Already there ⇒ do not invoice again. The delivery note moves to «Invoiced», marked «already in the accounting package» with the voucher number. When the sync pulls that invoice in, it is attached to the delivery note, so anyone who opens the note sees its invoice.
- From the cut-off date — the date the sync stops pulling sales invoices in — the ERP becomes the place that holds invoices: it invoices by what the supermarket received, then marks «Already in the accounting package» with the voucher number, so that it is never pushed back there again.
- Invoices pulled in from the accounting package are never pushed back. The push button disappears on these invoices, and if anyone calls it by another route, the push refuses.
- After each run, ask again. ERP invoices that have been made but not yet pushed are checked against the accounting books again — because the accountant may enter them after the machine has invoiced.
- Both directions, one rule. When the sync meets a sales voucher whose goods receipt number, PO number or ERP invoice number matches an existing ERP invoice, it pairs them and does not import — importing would be revenue counted twice in the ERP.
Pushing ERP invoices into the accounting package is a separate function; here it is enough to know that it also asks before writing.
When the accounting machine is off — often the case for the 7:30 run — the ERP cannot ask. At first the machine stopped completely («better late than duplicated»); there were no invoices any morning, so this was changed: it still invoices based on the latest sync, records clearly that the run could not ask, and leaves the after-run re-check and the pairing step during sync to catch whatever slips through.
2. What was measured on 30/10
| Case | Count | Value |
|---|---|---|
| Invoices the machine made that the accounting package also had — caught before pushing | 199 | 319.4 m |
| Delivery notes with an invoice pulled from the accounting package — attached, not invoiced again | 117 | 302.7 m |
| Delivery notes that asked the books before invoicing and found it already there — not invoiced | 6 | 66.7 m |
| Recognised as already there | 322 | 688.8 m |
Before these steps existed, 87 delivery notes that already had an invoice in the accounting package sat in the wrong section of the review screen — 60 «waiting for receipt», 13 «needs review», 14 «ready to invoice», inviting the accountant to invoice a second time. And one duplicate invoice really did happen: the very morning delivery note at the top of this article, before the ERP knew to ask directly.
688.8 million VND is revenue that would have been counted twice if no step had stopped it. It is not money earned, and the calculation below does not add it to the benefit. The real money lies in work that no longer has to be done.
3. Source one: no checking each invoice by hand
Without a machine that asks, the only way to be sure is for a person to look up each ERP invoice in the accounting package before allowing the push.
How to measure. Time checking 20 invoices in a row. Confidence: high, but small.
4. Source two: no tracing and unwinding duplicate invoices
How to measure. The number of invoices in both places is measured (the 95% above). The share people catch themselves is not — ask the chief accountant how many duplicate invoices the last move had to unwind, and when they were found.
Confidence: moderate. This is the largest source and it rests on a number that has to be asked, not counted: if your people catch nearly all of them, this source gets much smaller.
5. Source three: no cancelling or replacing e-invoices
A duplicate invoice that sits in the books can still be unwound internally. A duplicate invoice already issued as an e-invoice has to be cancelled or replaced through the formal procedure, and explained to the customer.
How to measure. Count the cancellation records and replacement invoices from the previous move. Confidence: moderate — possibly an underestimate, especially when the customer is a large chain and every replacement means another receivable reconciliation with them.
6. What has to be given back: the runs that could not ask
7. Adding it up
| Source | Money per move |
|---|---|
| No checking each invoice by hand | 0.39 m |
| No unwinding duplicate invoices | 3.32 m |
| No cancelling or replacing e-invoices | 1.00 m |
| Reviewing runs that could not ask | −0.01 m |
| Whole move | 4.69 m |
About 4.7 million VND, once, for a two-week move at 420 invoices a month. The figure is small next to the 285 million VND of revenue that would have been counted twice in the example — and that is the main point: the value of asking first lies not in labour saved, but in the books never being in a wrong state while waiting for someone to notice. A month closed with revenue counted twice is a wrong report already sent; the calculation cannot price that, and it does not try.
8. What assumptions this ROI rests on
Both sides carry a shared number. The question only works when the voucher in the accounting package carries the supermarket's goods receipt number or PO number. For a chain with no PO, the accounting voucher carries an internal number and there is nothing to compare — there the ERP blocks duplicates with the cut-off date: delivery notes before the cut-off date are not invoiced in the ERP.
The cut-off date must be read from one place. The ERP reads the cut-off date directly from the sync's configuration and keeps no copy; if the read fails, the machine takes the safe side — it does not invoice notes the accounting package already has. Two hand-copied cut-off dates in two places will drift apart on exactly the day that matters.
When the accounting machine is off, there is no question to ask. The early-morning run is when this happens most. The two after-run steps — asking again and pairing during sync — catch what slips through, but a few hours later. Count the «could not ask» runs each week; if the count is high, move the run time rather than drop the question.
95% only holds for the first weeks. It is the figure from while the accountant has not yet stopped entering invoices. The end of the move is when this figure drops to near 0 — and if it does not, someone is still doing the work twice.
9. Measure it in your own company
- Before the move. Record the number of invoices a month for the customer group that will move, and ask how many duplicate invoices the last move had to unwind, and over how long.
- During the move. Count each day: ERP invoices made, how many of them are «Already in the accounting package», notes not invoiced because they were already there, runs that could not ask. The «already there» share must fall over time.
- After the move. Count the real duplicate invoices left over: two vouchers for one PO number. The target is 0, and it can be measured with one query.
Further reading: before a delivery is invoiced at all, it also has to agree with what the store signed for — the signed delivery note, checked the same day covers that part.
10. What to remember
A duplicate invoice is born from two correct ways of working. The machine invoiced correctly, the accountant entered correctly; nobody asked the other. During a move, do not rely on people remembering to stop the old work; let the new place ask the old place before writing — and make sure everything pulled in from the old place never travels back.
Moving work to a new system does not mean the old system stops running. It means there is a period when both run.
The number of invoices in both places, the number of notes attached to pulled-in invoices, the number of notes not invoiced and their value were measured on the live system of a fresh-produce supplier to retail chains at 21:40 on 30/10/2026, anonymised. Invoices per month, the share people catch themselves, the share issued electronically, hours and wages are illustrative figures. Replace them with your own.
Read next
-
Sharing an estimate by one link: what the mailed-Excel loop costs, and "which version is the latest?"
An estimate passes through 2–4 people as Excel files sent by mail, so someone always asks "which version is the latest?". When the whole set — drawings, quantity table, where every number comes from — sits behind one shared project, with people invited by email or sent a view-only link that needs no account, how many hours a month does the review loop get back?
-
Invoicing at the original PO price: the delivery note says 21,000, the chain's PO says 30,000
A retail chain pays the price on its own PO, not the price on the supplier's delivery note. When a machine reads the PO price, invoices at it when the gap is plausible and corrects the price list for next time, what is that worth a month — and which lines still need a person?
-
Searching a scanned drawing set: 171 pages recognised in 338 seconds, and the paging hours that come back
In a drawing set, a scanned page yields nothing to Ctrl+F; looking up a mark means paging. Once every scanned page is recognised into text — text pages and scans counted separately, an interrupted run resuming where it stopped — how many hours a month does an estimator get back, and does the largest set even finish?