Inventory what the source localisation, tax codes and Crystal layouts satisfy today, and decide per requirement whether a Microsoft localisation, an ISV or Electronic reporting carries it forward.
Every other workstream on this path is signed off by someone inside the business. This one is signed off by a regulator, which changes its character entirely: there is no negotiating the deadline, no partial credit for a nearly correct return, and no sympathetic reviewer who understands that the programme was busy.
In SAP Business One, localisation is a property of the company database. The localisation chosen at creation shapes tax behaviour, statutory fields, available reports and document requirements, and it is not casually changed afterwards.
The register is the deliverable that makes the rest of the module tractable. One row per obligation, per country, per legal entity:
The posting engine established that tax codes carry accounts. This module addresses how the target decides which code applies, which is a different problem.
Crystal Reports layouts, saved queries and alerts produce a substantial share of what this estate sends outside the building. The gap register rates the migration of report and print logic as a medium-impact gap with a clear instruction: operational documents, alerts and reports must be triaged separately, and many should be retired…
Where the estate operates in a country with an e-invoicing or clearance mandate, this is usually the largest single item in the register and frequently sits in an add-on today.
Well supported: the structural difference in where localisation attaches; the target's group-intersection tax determination model; the instruction not to map tax by percentage; the requirement to triage the Crystal estate; the existence of localisation and patch-level variance as a material risk.
Localisation is the workstream a regulator signs, and on this path it is also the one with the most explicitly caveated evidence.