Two Weeks From Go-Live With 8,400 Orphan Records

The percentage is reassuring; the absolute number and the nature of the failures are not.

0.4% sounds trivial. But:

• 8,400 is a count of customers who may not be invoiceable. If their tax identifiers are missing, invoicing and tax reporting fail for them - a revenue and compliance consequence that persists until remediated, not a one-day cutover hiccup.
• The failures are not random. Missing tax IDs and duplicate addresses cluster - likely in a channel, region, or legacy system. That clustering means the affected customers may share an account manager or a billing cycle, so the commercial impact is concentrated rather than evenly spread.
• Duplicates are worse than omissions. A duplicate address can mean two records for one customer, which splits credit exposure and can double-invoice. That is a data-integrity problem that survives go-live silently.
• The AR reconciliation does not clear it. A USD 12,000 variance on USD 40 million looks immaterial, but AR is a balance and it reconciled on an aggregate basis - it says nothing about whether every customer record is complete and unique. Good aggregate reconciliation can mask individual record defects.

The dominant risk, therefore, is unbilled or mis-billed revenue after cutover with no clean way to identify the affected population, not 'some data didn't load'.

Conditional proceed is defensible; unconditional proceed is not, and neither is a flat delay if the 8,400 can be materially reduced in two weeks.

Required conditions before cutover:

1. Business-owned re-execution of critical end-to-end scenarios - order-to-cash, procure-to-pay, and at least one full period-end close simulation - run by business users, observed and signed by the process owners. Once, by the partner, is not evidence of repeatability.
2. A named owner for each defect class, with a written remediation plan for the 8,400: how many can be fixed pre-load, how many will be handled manually in the first billing cycle, and who does the manual work. Quantify the manual effort; if it exceeds available capacity, that is a de facto reason to delay.
3. A go/no-go gate at T-5 days with pre-agreed, measurable criteria (e.g. fewer than X unresolved records, all critical scenarios passed twice, reconciliation signed by the controller). Deciding at T-0 under launch pressure is not a decision.
4. Explicit rollback trigger criteria and a rehearsed rollback - the 60-day window is only useful if the trigger is defined before cutover, because in practice nobody calls a rollback during hypercare without one.
5. Defined hypercare exit criteria, not just a 30-day window, so that 'hypercare' does not quietly become the permanent operating model.

The auditor's role is to make sure the acceptance decision is made by the business owner with the data in front of them, in writing.

Weak assurance, on two independent grounds.

1. Independence. Roughly 30% of scripts were executed by the implementation partner who built the system. A builder testing its own work is a self-review threat; defects it introduced are exactly the ones it is least likely to detect and most likely to rationalise. The remaining 70% gives some coverage, but the gap is not randomly distributed - partners typically run the more technical or integration-heavy scripts.
2. Sufficiency. The order-to-cash end-to-end scenario ran once. A single pass shows the happy path can work; it does not show the process is repeatable or that exception paths behave. End-to-end scenarios are the ones most likely to surface cross-module integration defects, which is precisely what an ERP replacement introduces.

What to do:

• Do not treat the sign-off as sufficient evidence of readiness. Note it as a reliance limitation in the report rather than accepting it at face value.
• Require business re-execution of a targeted subset: all end-to-end scenarios plus any script touching revenue recognition, tax, or interfaces, executed by process owners.
• Review the defect log, not just the sign-off. Open and deferred defects, especially any deferred to post-go-live, tell you far more than a signature does. Ask who accepted each deferred defect and on what basis.

A sign-off is evidence that a document exists. It is only evidence of quality if you test who signed, what they ran, and what remained open when they did.