E-Invoice Extensions
In a growing list of countries, an invoice isn’t legal until the government’s platform has seen it — Brazil, India, Italy and more each run their own clearance regimes. REDA Financials prepares for this with a built-in e-invoicing extension point; country/provider extension packages complete the journey.
What the core provides
- E-Invoice Setup per entity: which country and environment apply to this legal entity, which document types are in scope, and whether invoices are filed automatically on posting or held for a person to release. See Setting up electronic invoicing for an entity.
- The E-Invoice Trail: one record per invoice holding the whole exchange with the authority — what was sent, what came back, the fiscal identifier it issued, and every retry. It is your audit evidence, and it appears in the E-Invoice Trails related list on the invoice. See Reading an E-Invoice Trail.
- Status on the invoice itself: two read-only fields, E-Invoice Status and E-Invoice UUID, so the position is visible without opening anything else — plus a Skip E-Invoicing checkbox to exclude an individual invoice. See Electronic invoicing on the Sales Invoice.
- The scheduled status poll: authorities that answer asynchronously are chased by the E-Invoice Status Poll, which moves submitted documents to their final verdict. Every organisation must schedule it themselves. See The E-Invoice Status Poll.
- Extensible documents: the configuration-driven design lets an extension add the country’s mandated fields to documents and PDFs without touching your core setup.
Core vs extension — who does what
| Piece | Core or extension? | What it gives you |
|---|---|---|
| E-invoice setup per entity | Core | The configuration slot: which provider serves this legal entity, and against which environment (test or production). |
| E-Invoice Trails on the invoice | Core | The per-document audit trail — every submission's status and the authority's responses, attached to the invoice itself. |
| Configuration-driven document extensibility | Core | The mechanism that lets a country's mandated fields appear on documents and PDFs without changing your core setup. |
| The provider connection | Extension | The actual link to the government platform or clearinghouse for a specific country and provider. |
| The mandated fields for a country | Extension | What the local regime requires on documents, added through the configurable field lists. |
Reading the submission trail
Each invoice gets one E-Invoice Trail, and it is reused for the whole life of that filing — a retry updates the same record rather than adding another. It carries the document's compliance story: what was sent, the authority's reply, the fiscal identifier, and how many attempts it took.
| Trail status | What it means | What to do |
|---|---|---|
| Draft / Ready to Send / Queued | Prepared, released and in line to be transmitted. Draft means the entity files manually and nobody has released this one yet. | Nothing, unless it is sitting at Draft — then somebody has to release it. |
| Submitted | The authority has the document and has acknowledged it, but has not ruled on it yet. | Nothing — provided the status poll is scheduled. Without it, nothing ever moves past this point. |
| Accepted | The authority cleared the invoice — it is legal in that jurisdiction, and the fiscal identifier is recorded. | Nothing — the Trail is your evidence. |
| Rejected | The authority refused it, and its reason came back with the response. | Read the reason, fix the cause, then correct the invoice with a credit memo and reissue. |
| Error | The exchange itself failed — the document never validly reached the authority. Different from a rejection. | A configuration or connection problem. Fix the cause, then retry the same Trail. |
| Cancelled | The document was withdrawn at the authority. | Nothing. |
The flow, once an extension is installed
Configure the entity
Install the country extension package, then create the entity’s E-Invoice Setup pointing at it — Sandbox environment first, Production only when certified. Then schedule the E-Invoice Status Poll: it is not included in the package, so every organisation must create it, and without it submitted invoices never reach a verdict.
Invoice as normal
Users create and post invoices exactly as this manual describes — e-invoicing rides on posting, not on new habits.
Track the trail
The status and the government’s response land on the invoice’s E-Invoice Trail, and the invoice itself shows E-Invoice Status. Rejections carry the authority’s reason; correct the cause and reissue with a credit memo, because a filed invoice can no longer be unposted.
A worked rollout — Meridian's Brazilian entity
Brazil runs one of the clearance regimes the intro names, so Meridian Properties Group's Brazilian entity can't treat e-invoicing as optional. The rollout follows the article's flow exactly:
Install and point at test
The administrator installs the provider's extension package and points the Brazilian entity's e-invoice setup at it — test environment first, as the configuration offers.
Prove it on the test environment
The AR team posts invoices exactly as always; each submission and response lands in the invoices' E-Invoice Trails. A rejection during testing arrives with the authority's reason — fixed and resubmitted, the next trail row reads accepted.
Switch to production when certified
One configuration change on the entity's e-invoice setup. Nothing changes for the invoice creators — e-invoicing rides on posting, not on new habits.
Meanwhile the US entity, with no clearance mandate, runs no e-invoicing at all — the extension point simply sits unused there, costing nothing.
Common mistakes to avoid
| Mistake | Why it hurts | Do this instead |
|---|---|---|
| Pointing the entity at production before certification | Real submissions to a real authority while you're still learning the regime | Test environment first, production when certified — the setup offers exactly that switch |
| Treating a rejection as a dead end | The invoice stalls while everyone debates | The authority's reason is on the trail — fix the cause and resubmit |
| Retraining invoice entry for the rollout | Wasted effort and worried users — the workflow doesn't change | E-invoicing rides on posting; communicate that, not new steps |
| Configuring e-invoicing for entities whose country has no mandate | Complexity with no compliance value | Configure per entity, mandate by mandate |
| Delaying entity and tax setup "until e-invoicing is sorted" | Backwards — the core is ready before any extension arrives | Set up the books now; nothing needs rework when the extension lands |
Where to go next
- Electronic invoicing: how it works — the concept and the end-to-end flow.
- Setting up electronic invoicing for an entity — the configuration, field by field.
- Reading an E-Invoice Trail — resolving a rejection or an error.
- The E-Invoice Status Poll — scheduling the job that collects verdicts. Required.
- Electronic invoicing on the Sales Invoice — what the AR team sees day to day.
- Extension Architecture — the pattern behind it.
- Understanding the Tax Engine — the compliance foundation e-invoicing rides on.
Frequently asked questions
No — they create and post invoices exactly as this manual describes. E-invoicing rides on posting; the submission and its trail happen around the document, not through new user steps.
On the invoice itself — the E-Invoice Trails related list records each submission's status and the authority's response, including the reason on a rejection.
It's a correction loop: the authority's reason arrives with the rejection, you fix the cause and resubmit, and every attempt stays on the trail as evidence of the process working.
Each entity's e-invoice setup points at one or the other. Test lets you prove the connection and the country's mandated fields safely; production is for when you're certified. The switch is one configuration change.
Nothing special — set up entities, tax and documents as normal. The core is ready, and nothing about today's setup needs rework when the country's extension arrives. Ask REDA about provider availability for your timetable.
Through the configuration-driven design: the extension adds them without touching your core setup. See Extension Architecture for the pattern.
Was this article helpful?