Ghana's E-VAT regime moved invoicing from something you print to something the Ghana Revenue Authority has to acknowledge before the document is valid. Finance teams running Dynamics 365 Business Central usually discover the gap at month end: the posted sales invoice is correct in the general ledger, but there is no fiscalised counterpart, no GRA reference on the customer's copy, and no defensible record of what was transmitted. The stopgap is a second system — a portal, a spreadsheet, or a third-party desktop tool — where someone re-keys invoices that Business Central already holds. That re-keying is where VAT rate mistakes, missing TIN details, duplicate submissions and unreconciled credit notes come from, and it is invisible to the ERP until an auditor asks.

Business Central out of the box handles Ghanaian VAT arithmetic well enough — VAT Posting Setup, VAT business and product posting groups, VAT statements and the VAT Entry ledger are all there. What it has no concept of is a document that must be registered externally, carry a state (queued, accepted, rejected), and be legally incomplete until the authority responds. There is no field to hold the GRA reference, no retry when a submission times out, no correction workflow when a document is rejected, and no archive of the exact payload that was sent. Localisation apps published for other markets do not fill this in for Ghana, and building it as one-off customisation tends to end up as code in a single company's tenant with no upgrade story.

We build this as a Business Central AL extension — delivered as a per-tenant extension or an AppSource-format app, whichever fits your deployment — that treats fiscalisation as a first-class document lifecycle. Table extensions on Sales Invoice Header, Sales Cr.Memo Header and their posted counterparts carry the E-VAT status, GRA reference, timestamp and response digest. Codeunit event subscribers on the posting flow (OnAfterPostSalesDoc and related publishers) hand the posted document to a submission codeunit rather than blocking the post itself, so a slow or unavailable authority endpoint never stops a shipment or a period close. A dedicated setup page maps your VAT posting groups, item and G/L account classifications, unit-of-measure codes and customer TIN fields onto the codes the E-VAT schema expects, so the mapping lives in configuration rather than in code. A Job Queue Entry drains the outbound queue on your schedule, applies bounded retries with backoff, and writes every attempt to an audit log. One posting produces both outputs: the human-readable invoice — a report layout carrying the GRA reference and verification code for the customer — and the machine format transmitted to the authority, derived from the same posted data so the two can never disagree.

Rejections are treated as a workflow, not an error dialog. A rejected document lands in an exceptions list with the authority's reason code and message resolved into readable text, an assignable owner, and a guided correction path — amend and resubmit, or issue a corrective credit note that carries the reference of the document it corrects. Nothing is silently retried into a duplicate. Every submission, response, retry and correction is retained with its payload in an archive table with its own permission set, so an audit question is answered from inside Business Central instead of from someone's inbox. Read access is exposed through API pages (REST API v2.0 / OData v4) so Power BI, a Power Automate flow or a Dataverse-connected app can report on compliance status without anyone opening a page.

This is build-to-order, not a download. It starts with a short scoping call where we confirm your Business Central version and deployment (SaaS or on-premises), your VAT setup, which document types are in scope, and the GRA credentials and endpoints your entity uses. From confirmed scope, typical delivery is one working week: we build against your release wave, install and configure it on your sandbox, run UAT with your finance team on real documents, then deploy to production with a rollback plan. You receive the AL source, the git repository, technical and user documentation, a training session, and a post-go-live support window during which we fix anything the live environment surfaces.