The Double-Entry Period: Surviving Six Weeks With Two Systems Live

A duplicate-entry period is not a data problem. It is a rule problem that presents as a data problem. The moment both systems are open, the business has silently adopted a new and unwritten rule: if the two records disagree, the one somebody is looking at right now is the one that is true.

That rule is not written anywhere, it is not applied consistently, and it is different for every person. The counter clerk entered the sale in the old system because that is where the customer is standing. The owner entered the same sale in the new system on Thursday evening, from a phone photograph of the bill, and got the amount right and the date wrong. By Friday there are two records, they disagree, and there is no rule that says which is real, so the question gets answered by whoever is more confident, and confidence is not the same as accuracy.

The disagreement is always about something small. The date. The payment method. Whether the customer paid the previous balance at the same time. Whether the discount applied. Whether a round-off was taken. Each one is trivial in isolation, and each one is now a fork in the record that nobody documented.

The illustrative table below follows a constructed six-week overlap. It counts sales, not money, and every column is defined so the rows can be checked by hand. Each row satisfies two sums: the old-system total equals the sales agreeing, plus the sales that disagree, plus the sales recorded only in the old system; and the same identity holds for the new system.

Read it for the shape rather than the figures. At the start of the overlap the two systems are identical, because everyone is entering both. By the end, the two systems have each recorded sales the other has not, the number of sales recorded in both systems but carrying a different value has climbed from nothing to three a week, and the totals have drifted apart by one sale.

Check week 4 against the identity: 37 agreeing plus 2 disagreeing plus 5 old-only is 44, which is the old-system total, and 37 plus 2 plus 3 is 42, the new-system total. Week 6 is the worst row and the most instructive: 31 agreeing, 3 disagreeing, 5 old-only, 7 new-only. The old system has 39 and the new has 41, so the new system is ahead by two sales on the week the business was supposed to be moving towards the new system. That is not a coincidence. By week 6 the counter is being faster in the system it is more confident with, and the disagreements have begun for the same reason: the discipline that produced identical records was never a rule anyone could follow, it was a habit that is now fading.

Across the whole overlap, the old system recorded 245 sales: 38 plus 41 is 79, plus 36 is 115, plus 44 is 159, plus 47 is 206, plus 39 is 245. The new system recorded 244: 38 plus 40 is 78, plus 38 is 116, plus 42 is 158, plus 45 is 203, plus 41 is 244. Twenty sales exist only in the old system and nineteen only in the new one, which is 20 plus 19, or 39 sales that exist in one system and have no counterpart in the other. Nine of those sales were entered in both systems with a different value attached.

Take one of the nine. A sale is entered in both systems in week 5. In the old system it is invoice INV-2291 with a total of 48,380. In the new system the same sale has no payment recorded against it at all. The customer paid, once, in cash, at the counter.

The arithmetic on the invoice is the standard constructed example used through this article, and the 18% GST figure appears only so the total can be checked by hand: a base of 41,000 with 18% added gives a tax amount of 7,380, because 41,000 multiplied by 0.18 is 7,380, and 41,000 plus 7,380 is 48,380. The tax treatment of a real transaction is a question for your own chartered accountant, not for this article.

So the old system says 48,380 collected. The new system says nothing collected. The difference in collections between the two systems is 48,380, and both figures are being reported to somebody. Whichever one is wrong, the business has either shown a customer as a defaulter when they are not, or lost 48,380 of visibility into money that genuinely arrived. Neither error announces itself. A collections report that is short by one invoice reads exactly like a collections report that is short by one customer who has not paid.

The switch is one day and it gets attention. The overlap is six weeks and it gets none, because every day of it looks like a normal day. The counter is billing. The owner is checking. Something is running. What is not visible is that the business is now maintaining two ledgers, and the reconciliation between them is being done by whoever remembers to do it.

Three specific things go wrong in an overlap that does not go wrong in a single-system world.

The first is double counting. A sale entered in both systems is one sale, but it appears twice in any report that reads both files. If the owner builds a consolidated view by adding the two systems together, the overlap inflates the number. If the owner builds it by preferring the new system, the old system's unentered sales quietly disappear. Both are reasonable implementations of an unwritten rule, and they produce opposite errors from the same data.

The second is the orphan. A sale entered only in the old system during the overlap is a real sale that the new system has never heard of. It is not visible in the new system at all, so it cannot be chased, cannot be aged, and cannot be put in an invoice run. In the constructed table above that is 20 sales by the end of week 6. Each is small. Together they are a period in which the new system under-reports the business, and the shortfall is invisible precisely because the new system is the one being trusted.

The third is the confidence problem. By week 4, the counter clerk has stopped entering into both systems for a few sales here and there, not as a decision but as an omission. Nobody writes down that this has started. At week 6 the new system has 7 sales the old one does not and the old one has 5 the new one does not, and both people involved believe the other system is complete.

The rule has to name a system and a date, before the overlap starts. Not a person and an intention. Something like: from the first working day of the overlap, the old system is the record for invoices raised up to and including the cutover date, and the new system is the record for everything after it. The two overlap in the sense that both are open, not in the sense that both claim to be authoritative.

Without this sentence, every disagreement becomes a fresh negotiation, and the negotiation is always lost by the person who is not the owner.

This is the part that gets skipped, and it is the part that determines whether the migration is reversible. The rule needs six things stated in advance, in one page, signed by whoever can be asked to produce it later.

The old system should be closed on a boundary the business already understands, and the day-end close is the obvious candidate. In the constructed example, the counter closes each day with expected cash, counted cash, and a variance. Closing the old system the same way means the last thing you do with it is the same thing you do every night, which is a discipline the business already has rather than one it has to invent under pressure.

This is worth being precise about, because shift close and day-end reconciliation are assisted-setup maturity rather than self-serve switches. That is not a hedge, it is the honest description: the close is configured with you as part of setup, and its quality depends on the counter having run a clean close for a while before you depend on it. If the old system is not currently closed properly every night, do not make the migration depend on it. Close the old system on whatever boundary it does have, and say so in the rule.

The useful test for a cutover date is whether you can describe it to the counter clerk in one sentence without using the word and. A date they can repeat is a date they will respect. Six weeks after the switch, the only question that matters is whether the boundary held, and a boundary that nobody can state is a boundary that will not hold.

A migration is not a data transfer, it is a change of what the business is willing to record. Some of what the old system held has no destination, and pretending otherwise is how a migration ends with a shadow spreadsheet two systems in.

There is no timesheet record and no payroll module here, so a spreadsheet that tracked staff hours has to go somewhere else or stop. Expenses are a Nox-Billings capability and purchasing lives in the Commerce area, so a purchasing sheet does not have a home in the billing records. There is no change-request record, no milestone record and no deliverable record, and no contract editor or e-signature, which means a change of scope during the overlap becomes a new quote raised against the same project rather than an edit to the old one. NoxOrigin does not file GST returns or any other statutory return, so the old system is not going to stop being the source for that either; where a statutory rule matters, ask your own chartered accountant.

Migration is scoped work, not a self-serve import. If the plan says the data will be loaded for you, that is a statement about a deployment being configured with you, and it is worth asking what the loading process checks. A file that nobody has read, loaded without review, arrives as a list of confident errors.