Since October 2023, a Japanese buyer can only claim the consumption-tax input credit on a purchase if the seller issued a qualified invoice (適格請求書) as a registered qualified invoice issuer. That puts a very specific burden on the seller's billing system: every invoice must carry the issuer's registration number, separate the 10% standard and 8% reduced rates, state the tax base and consumption-tax amount per rate, and stay consistent between the human-readable document the customer files and any machine-readable copy sent downstream. Dynamics 365 Business Central gives you a solid VAT engine out of the box — VAT posting setup, VAT business and product posting groups, VAT entries, VAT statements — but the Japanese layer sits above that. There is no first-class validated field for the registration number, no per-rate qualified-invoice block on the standard sales invoice layout, no qualified return invoice (返還インボイス) as a distinct legal document type, and no correction workflow that ties a rejected or amended invoice back to the original with an auditable link.

What we build is a per-tenant AL extension — or an AppSource-track app where you prefer that lifecycle — that closes exactly that gap without forking your posting logic. Table extensions put the qualified-invoice attributes where they belong: the issuer registration number on Company Information, held per legal entity so multi-company tenants work properly; customer-side registration numbers on Customer with format validation; and a qualified-invoice header block on Sales Invoice Header and Sales Cr.Memo Header so posted documents remain self-describing years later. A dedicated mapping table resolves each line's VAT business and product posting group combination to a Japanese consumption-tax rate class — standard, reduced, exempt, or out-of-scope — so categorisation comes from your existing master data rather than a spreadsheet somebody maintains on the side.

Codeunits subscribe to the standard posting publishers, including OnAfterPostSalesDoc and the release and validation events, to snapshot the per-rate totals at the moment of posting. That single snapshot is what makes the human-readable document and the machine format provably identical: both are rendered from one persisted set of totals rather than recalculated twice in two places. On output we ship a qualified-invoice report layout — Word or RDLC, extending the design you already use — printing the registration number, the per-rate tax base and consumption-tax amounts, and the reduced-rate line markers required for 軽減税率 items, alongside a machine-readable export in structured XML or JSON, shaped to a Peppol BIS JP-PINT profile where your trading partners or a receiving network demand it. Generation, transmission and retry run as job queue entries, so nothing depends on a user having a session open, and every attempt is logged.

When a counterparty or a receiving portal rejects a document, the rejection is captured against the invoice with its reason code and routed into a correction workflow: the extension creates the corrective document, links it bidirectionally to the original, and blocks silent re-issue of a document that has already been accepted, with an explicit supervisor override where a genuine amendment is needed. Archiving retains the exact rendered artefact — not a regenerated approximation — together with the response payloads for the statutory retention period, and an audit factbox on the posted invoice exposes the whole chain. Access is governed by purpose-built permission sets so a clerk can issue while a controller corrects, and API pages published over REST API v2.0 and OData v4 let Power Automate, Dataverse, or your own middleware read compliance status without touching the database directly. Telemetry goes to Application Insights so failures surface before a filing deadline rather than after one.

This is build-to-order, not an AppSource download you install this afternoon. We begin with a scoping call to map your real situation: how many legal entities are in scope, which rate classes actually appear in your item and G/L master data, whether you invoice businesses, consumers or both, what your customers expect to receive and in what format, and whether you run Business Central online or on-premises. We then build against your current release wave, validate on a sandbox restored from production data, run UAT against a written acceptance checklist with a documented rollback plan, and hand over the AL source in a git repository you own. Typical delivery is two to four weeks from confirmed scope — faster for a single company on current SaaS with clean VAT posting setup, longer where multiple entities, heavily customised layouts, or a partner-mandated transmission format are involved. Nothing is charged before scope is confirmed and quoted in writing.