Finance teams invoicing in Ghana carry an obligation ERPNext core was never designed for: every taxable sale has to be presented to the Ghana Revenue Authority in the GRA's own machine format, carry the fiscal identifiers the GRA returns, and be reproducible on demand years later. Out of the box, ERPNext gives you a Sales Invoice, a Sales Taxes and Charges Template, and a print format. It does not give you a fiscalisation state on the document, a queue that retries a failed transmission, a place to store the GRA response identifiers against the invoice, or a legal way to correct a document that has already been fiscalised. Most teams end up with a parallel spreadsheet and a person who re-keys invoices into a portal — which is slow, unauditable, and breaks the moment volume grows or that person is on leave.

We build a proper Frappe app — its own module, its own DocTypes, installed on your bench alongside ERPNext rather than patched into it. The core is a Ghana E-VAT Settings single DocType holding endpoint, credentials and environment (sandbox vs live), plus a child DocType that maps your ERPNext tax accounts and Item Tax Templates onto the GRA's tax categories and rate codes, so the classification lives in master data and not in code. A hooks.py doc event on Sales Invoice.on_submit builds the payload from the submitted document, and a queued background job (never the web request) performs the transmission, so a slow or unreachable GRA endpoint can never block a user pressing Submit. Every attempt is written to a Ghana E-VAT Transmission Log DocType: request payload, response body, HTTP status, timestamp, and the operator who triggered it — an append-only trail you can hand an auditor.

The same posting produces both outputs the law and the customer need. The machine format is generated from the invoice's own fields — no re-keying — while a Frappe print format renders the human-readable invoice carrying the GRA identifiers, the QR or verification data returned on acceptance, and the fiscal reference, so the document a customer receives and the document the GRA holds are provably the same posting. Rejections are treated as a first-class state rather than an error: the invoice carries a fiscalisation status field (Pending, Queued, Accepted, Rejected, Cancelled) with the GRA's reason code and message rendered inline via a client script, a list-view indicator so finance can see the whole backlog at a glance, and a correction workflow that produces a properly linked credit note or re-submission rather than silently editing a submitted document. A scheduler event sweeps stuck and rejected records on your chosen cadence and can alert a role, so nothing sits unnoticed until month end. Whitelisted methods expose retry, status refresh and bulk re-submission over the Frappe REST API for your own tooling, and a dedicated role plus role profile keeps credentials and manual re-submission away from ordinary invoice clerks.

This is build-to-order, not a marketplace download. We start with a short scoping call to confirm your GRA registration status, invoice volume, tax categories in use, ERPNext version and any customisations already on Sales Invoice. We then build against your actual bench and your Frappe/ERPNext version — v15 and v16 are both supported — deliver to a staging site for UAT with your own invoices, and only then go live with a documented rollback. Typical delivery is one working week from confirmed scope. You receive the full source in a git repository you own, so nothing about your compliance depends on our continued involvement.