Finance teams invoicing in Ghana face a problem Odoo core was never designed for: the Ghana Revenue Authority does not accept a PDF you printed and emailed. An E-VAT invoice has to be transmitted in the Authority's expected structure, carry the identifiers the Authority returns, and be reproducible on demand for audit years later. Odoo's native account.move gives you the accounting truth and a QWeb PDF, but nothing downstream of action_post — no submission state, no response identifier stored against the invoice, no way to tell an accountant that the invoice they posted this morning was rejected this afternoon and why. Teams fill that hole with a second system: a portal someone re-keys into, a spreadsheet of reference numbers, and a monthly reconciliation that nobody enjoys. Every re-keyed field is a mismatch waiting to be found by an auditor.

What ECOSIRE builds is a compliance layer that lives inside the invoice record, not beside it. We extend account.move with the E-VAT fields the flow actually needs — submission state, Authority response identifiers, response timestamps, the raw response payload, and a rejection reason — and drive them from a state machine hung off invoice posting rather than a manual button someone forgets. Tax mapping comes from your existing master data, not a parallel table: account.tax and account.fiscal.position already encode which rate applies to which customer and product, so the module reads that mapping and translates it into the codes the Authority expects, with a validation pass that refuses to submit an invoice whose tax lines cannot be mapped cleanly. One posting produces both outputs: the machine format for transmission and the human-readable QWeb report your customer receives, rendered from the same record so the two can never diverge in figures.

Technically, the module ships as a standard Odoo addon with its own __manifest__.py, models under models/, XML and OWL view extensions, QWeb report templates, and an ir.model.access.csv plus record rules so that E-VAT operations are scoped — an invoicing clerk can submit, only a finance manager can force a correction or re-submit. Transmission runs through a queued job rather than the request thread, so a slow or unavailable Authority endpoint never blocks a user posting an invoice; failures are retried on a schedule via ir.cron and surfaced on the invoice in a way that is visible from the list view, not buried in the log. Rejections open a correction workflow: the original stays immutable, the reason is recorded in the chatter with the mail thread intact, and the corrected document carries an explicit link back to what it replaces. Every request and response is archived as an ir.attachment against the move, giving you a byte-exact audit trail rather than a reconstruction. Everything is reachable over XML-RPC and JSON-RPC, so a fulfilment system or an external portal can trigger and read submission state without a human in the loop. We build against Odoo 17.0, 18.0 or 19.0 and we work on Community as well as Enterprise — where a capability genuinely depends on Enterprise (for example if your process leans on Odoo Studio or the Enterprise document tooling), we say so during scoping instead of after delivery.

This is build-to-order, and we are explicit about what that means. There is no instant download; when you request a quotation we start with a short scoping call to confirm your Odoo version and edition, your chart of accounts and tax configuration, whether you invoice from Sales, Subscriptions, POS or an external system, and how your finance team wants rejections to reach them. From confirmed scope, typical delivery is one working week. You receive installable source for your exact version, we install and configure it, we run UAT on a staging database with your own data before anything touches production, and we hand over the git repository so the code is yours. After go-live you have a support window in which we fix defects in what we built.

One honest caveat worth stating up front: regulatory requirements in Ghana continue to evolve, and any integration is bound to the Authority's current interface and rules. We build to what is documented and in force at the time of your scope, we design the mapping layer so codes and formats are configuration rather than hard-coded constants, and we handle changes after the support window as a scoped update rather than pretending a module can be permanently future-proof.