For any invoice your business transmitted eighteen months ago, you should be able to name the mapping version that was live when it went out. Most enterprises building toward January 2027 cannot answer that question, because almost nobody is building for it.

The readiness work underway across the market is overwhelmingly current-state work: can the ERP generate a valid invoice today, does the ASP connection pass conformance testing today, does today’s master data support today’s determination logic. Those are necessary questions. The question a Federal Tax Authority query asks two years from now is a historical one: what did this specific transaction assert, on what basis, and can you show your working.

The Six Questions

Replayability is the enterprise’s capacity to reconstruct the data, evidence, mapping logic and system path that applied when a specific transaction was created and transmitted. For any authority-facing transaction, a business with genuine replayability can answer six questions: which source values existed, which mapping version applied, which transformation rules were executed, which defaults or overrides were applied, which payload was transmitted, and which acknowledgement or response was received.

Reconciliation — the discipline most businesses are actually building for — compares the enterprise’s internal records against the authority-facing representation to confirm the same transaction truth was preserved through transformation. That is one application of replayability, and the narrower one. Reconciliation tells you whether today’s numbers match. Replayability tells you why a transaction transmitted the way it did eighteen months ago, under a mapping configuration that no longer exists.

Why Current-State Knowledge Is Not Enough

Internal systems and the PINT-AE specification evolve on different schedules. An ERP upgrade, a schematron amendment, a change to a code list, a revised interpretation of a supply type — each one is a potential change on either side of the mapping, and each change creates the possibility of mapping drift between what the system did then and what it does now. Knowing precisely how the system works today does not reconstruct how it worked when a transaction from Q2 2027 was actually generated. The two facts can diverge silently, and they diverge more the longer the gap between transmission and query.

This is the practical meaning of Transaction Truth as the framework uses it: a transaction was correct at the moment it was created, and the business retains the capacity to demonstrate, after the fact, exactly how that correctness was arrived at — which values, which rules, which version of the logic.

What This Requires in Practice

Building replayability means version-controlling mapping logic rather than treating it as configuration that simply gets updated in place. It means preserving the source values, the transformation rules and the transmitted output applicable to each historical transaction, alongside the current configuration those transactions happen to still resemble. It means the enterprise can answer an authority query about a transaction from any prior period with the specific facts that applied then, rather than a description of how the system currently behaves.

Most enterprises approaching go-live have built, or are building, for the first question — can we produce a correct invoice today. Very few have built for the second — can we explain, on demand, a transaction from a year and a half ago, using the mapping version that was actually live at the time. The gap between those two capabilities is where an FTA query in 2028 will land, and it is a gap current readiness programmes are largely not addressing.