# Draft reply to James — 2026-07-26 (rev 3, reconciled against the 2nd test load)

Hi James,

Thanks for pulling that together — it did exactly what we needed. I've audited your
dump against a fresh load into our test system, and we can now account for every
single line of difference between the two.

**The short version: it wasn't the amounts. Batches of invoices were being silently
skipped on import. Those are fixed, and of your 1,684 invoices we now match 1,683.
The single exception is one invoice for $49.50 that has no customer on it in MYOB.**

## What was wrong, and what we've fixed

1. **17 customer accounts didn't exist in Evolution as customers.** Thirteen were
   already in the system but only on the supplier side, so when the import looked for
   the customer it found nothing and skipped the invoice. Those 13 are now flagged as
   customers as well, and we've created the 4 that were genuinely missing (Peter
   Belcher Repairs, Jeff Peck, VooDoo Engines, CHR Pty Ltd). 

   This fixes what would have been a hole in the Xero import as well. 

2. **A customer/supplier ID clash in MYOB.** MYOB re-uses the same ID numbers on both
   sides — ID 1061 is "Lowes Petroleum" as a supplier but "APPS" as a customer. Left
   alone that would eventually have posted invoices to the wrong account. We've added
   a dedicated MYOB customer-ID field so the two can't cross over.

3. **Cash sales weren't mapping.** All counter sales come through under customer
   ID 0, which didn't match anything. That now points at the CASH account.

4. **Olympic Fencing was sitting inactive** in Evolution despite having 67 invoices.
   Now active.

5. **Invoices were arriving with no line detail and landing as $0.00.** Our two
   extracts — one for invoice headers, one for the lines — were selecting different
   sets of invoices, so a batch of headers arrived with nothing attached. Fixed; the
   current load has no $0.00 invoices in it apart from one that genuinely is nil
   (196799, which you also have at $0.00).

6. **Credit notes were being dropped entirely.** Our extract was testing for "still
   outstanding" in a way that only worked for positive amounts, so an unapplied credit
   read as settled and was left behind. Fixed — and it brought in 15 credits worth
   **−$11,501.16**, eight of which were on your dump and seven of which weren't.
   One of those seven materially changes the aged-debt picture; see below.

## Where the reconciliation sits

Comparing your dump against our load like-for-like — both to 23 July, which is where
your dump stops:

| | Invoices | Value |
|---|---|---|
| Your MYOB dump (to 23 July) | 1,684 | $515,069.06 |
| **Matched in Evolution** | **1,683** | |
| In MYOB, missing from Evolution | 1 | $49.50 |

Before these fixes, 317 invoices worth $103,154 were missing. It is now one, and it's
the only thing in this whole reconciliation we need you for:

> **196259, 02/07/2026, $49.50, order ref "195205-CARD"** — no customer ID and no
> customer name against it in MYOB. Who does it belong to?

Everything else ties out. On the 1,683 matched invoices the only differences are six
we believe are part-paid (below), one credit two dollars apart, and twelve out by a
single cent from GST rounding — 13 cents across the lot.

**One credit to check: CR151435, 11/05/2026.** Your dump has it at $108.00, we have it
at $110.00. A flat $2.00, not a rounding artifact, so one of the two figures is being
read from a different field. Not urgent, but worth knowing which is right.

## Aged debt, and a recommendation on where to draw the line

Now it's all loaded we can age it properly, and the ledger is in good shape:
**$532,235 of the $580,469 is under three months old.**

| Age at 30/06/2026 | Invoices | Value |
|---|---|---|
| Under 3 months | 1,727 | $532,234.54 |
| 3–12 months | 24 | $4,662.27 |
| 1–2 years | 4 | $11,165.57 |
| 2–3 years | 3 | $14,133.85 |
| 3–4 years | 4 | $18,272.84 |
| 4+ years | 10 | $0.00 |

**Good news on the oldest bucket.** We'd previously flagged nine 2008 invoices against
Peter Belcher Repairs, $1,219.93, as the worst of the aged tail. Once credits came in
we found a credit note dated 24/01/2011 for exactly −$1,219.93 against that same
account. **It nets to zero** — that debt was written off fifteen years ago and was only
showing as open because the credit wasn't coming through. Nothing to decide there.

**Our recommendation: set the migration cut-off at 1 July 2024 and don't bring
anything older across.**

That's a clean, defensible line — two full financial years of history — and it's a
setting on the import, so it's a one-word change rather than a manual clean-up. It
brings across 1,755 invoices worth $548,062.38 and drops 17 records:

- the ten Peter Belcher records above, which net to **$0.00** — so dropping them
  changes your receivables by nothing at all; and
- **seven CASH-account invoices totalling $32,406.69**, dated 2023–24.

So the real effect of the cut-off is $32,406.69, and all of it is the CASH group:

| Invoice | Date | Amount |
|---|---|---|
| 259689 | 21/02/2023 | $6,857.10 |
| 273115 | 29/09/2023 | $5,260.09 |
| 274072 | 23/10/2023 | $5,048.40 |
| 264622 | 26/04/2023 | $4,050.86 |
| 266071 | 25/05/2023 | $3,928.09 |
| 279884 | 20/02/2024 | $3,825.36 |
| 261082 | 22/03/2023 | $3,436.79 |

These carry customer ID 0 in MYOB, which is the counter-sale account — but your
current-year cash sales average around $117, so these clearly aren't counter sales.
They look like old cash-drawer entries that were never cleared.

Worth flagging: they come through as *outstanding* on our extract, but they don't
appear in your open-invoice dump at all. So MYOB is reporting them differently
depending on how it's asked. If your dump is the accurate one, they shouldn't be
carried across under any cut-off.

**One thing to decide.** A 1 July 2024 cut-off leaves in three more invoices from the
same CASH group — 289633 and 289635 (09/09/2024, $2,540.40 each) and 290513
(30/09/2024, $6,546.77), **$11,627.57 together**. Same pattern as the seven above,
and equally absent from your dump.

We'd suggest dealing with those three individually rather than moving the cut-off to
catch them, because a later cut-off would also drop a genuine credit: **CR175417,
25/10/2024, −$462.00**, which is real money owed back to a live customer. Tell us
whether to bring those three CASH invoices across and we'll set it either way.

That leaves the 24 invoices in the 3–12 month bucket ($4,662.27) as the only other
judgement call — small enough you may just want to bring them across and chase them
normally. Happy to go either way on those.

## Two smaller things to confirm

**1. Two invoices are in Evolution but not in your dump**, totalling $16,313.72:

| Invoice | Date | Amount |
|---|---|---|
| 193731 | 07/05/2026 | $15,392.03 |
| 185029 | 02/07/2025 | $921.69 |

Were these paid or voided in MYOB after your dump was taken? The $15k one is worth a
look. (We'd previously asked about a third, 193557 at $771.98 — the credits answered
that one: there's a CR193557 for exactly −$771.98 on the same account, so it's
credited and nets to nil.)

**2. Six invoices where Evolution is higher than your figure** — 191834, 190829,
194004, 193202, 193849 and 193623, about $468 between them. Our best guess is these
are part-paid: your dump shows the balance still outstanding, whereas we're loading
the full invoice value because we're not currently bringing payment history across.
If you can confirm that's what they are, we'll know the difference is expected.

## Two notes on your dump — neither is a problem for us

**Amounts.** Credits and returns are written in brackets, e.g. `(618.60)`. We've
matched them all correctly, and every one ties to the cent against our load bar the
CR151435 two dollars mentioned earlier — just flagging the format in case your own
comparisons read them as positives.

**Blank customer IDs.** Ten rows have the customer ID column empty, or the customer
name shifted into it — three Allied Cranes Hire and six Lucas Drilling, plus 196259
above. It hasn't caused us a problem (we pull our import data separately, and all
nine of those invoices are loaded against the right customers), but it will make your
own comparisons look worse than they are, so it's worth knowing the query drops the
ID on those rows.

Lastly, your dump appears to have been taken partway through 23 July — we have 34
invoices on that date and you have 8. Nothing wrong with either set, it just means
the last day isn't directly comparable which at this point is academic. 

Send the two new files through whenever suits and we'll audit them the same way.

Cheers,
Shane