The invoices that will cause the most trouble on 1 January 2027 are the ones raised in December against orders placed in November. With ASP appointment now required by 30 October 2026 and go-live fixed at 1 January 2027, most large businesses are working with under ten weeks between provider onboarding and a cutover that straddles both a year-end and a VAT period boundary.

Cutovers fail on governance. Network connectivity, ASP certification, ERP configuration and UAT sign-off receive the most scrutiny in any go-live readiness review; the governance conditions receive far less, and a cutover that is technically clean but governance-unprepared produces confusion in the first forty-eight hours that is indistinguishable from a genuine technical failure.

Open Transactions

The hardest problem is the transactions that straddle the cutover date: orders placed before go-live and invoiced after, contracts spanning the transition, credit notes relating to pre-cutover invoices, recurring billing that crosses the boundary. Each of these needs a documented treatment decision before the cutover begins, rather than a judgement call made on the day by whoever happens to be handling the transaction.

Three questions need written answers in advance: how will each open transaction type be classified — through the legacy pipeline or the new one; who carries the authority to decide ambiguous cases; and what is the authority-visibility implication of each option. That last question is the one most often left unresolved. An open sales order completed and invoiced through the new five-corner exchange appears in the authority’s structured data immediately. The same order invoiced through the legacy process does not appear until that process’s own reporting cycle runs. Where both pipelines are live concurrently, the authority’s data will reflect the new pipeline’s activity but not the legacy pipeline’s — a period position that understates actual activity until the legacy transactions are reconciled. The enterprise has to be able to explain that gap, and no system will flag it, because nothing has technically failed.

Big-Bang Versus Phased

The choice between a single cutover event and a phased rollout is frequently made on the wrong grounds — operational simplicity against risk management — while underweighting the governance cost of the transition period itself. A phased approach means running two live pipelines simultaneously, each producing its own position, both feeding the same authority data environment. That reconciliation and classification challenge is a governance obligation that has to be designed, resourced and owned from the moment phased cutover is chosen, and it lasts as long as both pipelines run. The deciding question is whether the enterprise’s people and systems can actually manage two concurrent pipelines without creating unexplained positions in the authority’s data. If the honest answer is uncertain, the governance cost of that uncertainty across two pipelines typically exceeds the risk of a well-prepared big-bang.

The Go-Live Command Centre and Hypercare

A functioning cutover needs a named authority matrix — who can decide, during the window, to hold a transaction cohort, pause a pipeline or trigger a rollback — a defined watching brief for what each person monitors and at what frequency, and a communication protocol covering the business, the ASP and the authority. None of this can be resolved by discussion once the window has opened; it has to be agreed before it does.

Hypercare that follows should operate at a genuinely different threshold from normal operations: a lower trigger for escalation, a shorter reconciliation cycle, active surfacing of issues before they become patterns. It should also be staffed with tax decision authority alongside technical support — the first two weeks of live running generate determination questions no runbook anticipated, and a technical team without tax judgement in the room can only log the question and wait. Hypercare ends on a condition: sufficient transaction volume processed across the full type range to confirm the controls are operating as designed and that reconciliation differences are explainable rather than unexplained. A date-based end without that confirmation is a governance risk dressed as project management.