Testing a mandate go-live: from Schematron green to end-to-end with the authority

"The validator is green, we're ready." It is the most dangerous sentence in a mandate project, because a passing Schematron proves only that your file is well-formed against one set of rules on your own machine. It says nothing about whether the tax authority will accept it, whether your counterparty can read it, or what happens when something goes wrong. A real go-live is a stack of test layers, and local validation is the first and easiest of them. Here is the full stack, and the order to build it in.

1. Why green is only the start

Local validation answers one question: does this document satisfy the rules I have implemented, as I have implemented them? That is necessary and it is nowhere near sufficient. Your Schematron may be a version behind; the authority may run additional checks it does not publish; the receiver may apply its own national rules; a code list may have moved. We have written separately about why a passing Schematron still gets rejected — testing is how you find those gaps before production does.

The mental model to adopt: each test layer exercises a different relationship — with the specification, with the network, with the authority, with the counterparty — and a green light in one says nothing about the others.

2. The six test layers

Most projects build layer 1, touch layer 3 once, and declare victory. The defects live in layers 4, 5 and 6 — the relationships with other parties and with failure — which is exactly why they surface in production.

3. The order that de-risks fastest

The layers are not sequential gates so much as a widening blast radius, and the cheapest way to work is to widen it early rather than late.

1. Static validation, in CI, from day one. Cheap, fast, and it should never regress — wire it into the build.
2. Conformance next, against the specification's published test files. Where accreditation requires passing a formal suite, this doubles as a gating deliverable with its own lead time — start it early.
3. Get onto the authority sandbox as soon as it will have you. This is the layer that most often surprises, because the real platform enforces things the published Schematron does not. Sandboxes also have access queues and their own quirks; the sooner you are on, the sooner you learn.
4. Round-trip with a real counterparty — a pilot customer or a second access point — before the population arrives. Delivery and legibility at the far end are only proven end to end.

4. Test the unhappy paths deliberately

The happy path — one clean invoice, accepted — is the demo, not the test. The cases that break in production are the ones teams never rehearse, so make each of them an explicit test:

• Authority rejection. Submit a document you know is invalid and confirm you receive, parse and surface the rejection — in a form a business user can act on, not a raw fault code.
• Corrections. Full credit note, partial credit, correction-of-a-correction, cancellation — each referencing the original correctly. This is its own minefield; see credit notes, corrections and cancellations.
• Counterparty rejection. A business-level "no" is different from a validity "no" — confirm your system routes and shows them differently.
• Outage and timeout. Kill the connection mid-submit and confirm you land in a resolvable "unknown" state, not a duplicate or a silent drop — the whole subject of designing for clearance outages.
• Duplicate submission. Retry the same document and confirm you do not create two cleared invoices.

A test plan that only proves the happy path proves the one scenario production is least likely to throw at you first.

5. The non-functional tests people skip

Finally, the layer that gets cut when the date gets close — and then causes the incident in week one:

• Volume. Run a realistic peak (month-end, not a Tuesday) through the whole path. Clearance latency that is fine for ten invoices can fall over at ten thousand.
• Deadline behaviour. Where the regime imposes a reporting window or an issuance deadline, test that your system actually meets it under load, and alerts you when it will not.
• Recovery. Take the sandbox (or a simulated dependency) down, bring it back, and confirm the backlog drains on its own without manual nursing or duplicates.
• Version drift. Have a rehearsal for the next schema or code-list version — these regimes re-issue specifications regularly, and "we passed once" is not "we stay passing".

Do the full stack and go-live becomes an anticlimax, which is the goal. The teams that treat a green validator as the finish line are the ones debugging tax-relevant documents in production under a statutory clock — and by then every party you did not test with is watching.