REDA One Help Center
EN
Language
English EN Español ES Português PT Italiano coming soon Français FR Deutsch coming soon العربية coming soon
reda.one ↗
Home / REDA Financials AI / Administration / Electronic Invoicing / Electronic invoicing: how it works

Electronic invoicing: how it works

In a growing number of countries an invoice is not legally an invoice until the tax authority has seen it and issued it an official number. Paper and PDF are the record; the government's copy is the truth. This article explains what that means in practice, what REDA Financials does about it, and what has to be set up before any of it happens.

New to this? Start here, then follow the links at the end. If you already know what electronic invoicing is and just need to switch it on, go straight to Setting up electronic invoicing for an entity.

What "electronic invoicing" actually means

Electronic invoicing — often written e-invoicing — is a legal requirement, not a convenience feature. Where it applies, every sales invoice must be sent to the tax authority in a structured format, and the authority replies with a decision and a unique fiscal identifier. Only then is the document valid to give to your customer.

It is worth being precise about three things people often merge together:

This is not……the same as this
Emailing a PDF invoiceSending the invoice to the tax authority in a structured, machine-readable form and receiving an official ruling on it. A PDF is a picture of an invoice; e-invoicing is a filing.
Posting the invoicePosting records the invoice in your own books. Filing tells the government it exists. Both must happen, and they are separate events.
A number your system generatesThe fiscal identifier is issued by the authority, not by you. It is the proof the document was filed and accepted.

Because the authority is a third party, it answers on its own schedule — sometimes in seconds, sometimes hours later, and slower at month-end when everyone files at once. That single fact shapes the whole design of the feature.

The four pieces

Electronic invoicing in REDA Financials is made of four parts. Understanding what each one is makes the setup steps obvious rather than arbitrary.

PieceWhat it isWho touches it
E-Invoice SetupOne configuration record per entity: which country, which document types are in scope, and whether invoices are filed automatically on posting or held for a person to release. No Setup record means that entity does not file electronically.Administrator, once
E-Invoice TrailOne record per invoice — the complete conversation with the authority. What was sent, what came back, the fiscal identifier, and every retry. This is your audit evidence.Created automatically; read by accounting and audit
The status pollA continuously running loop that transmits anything still queued and asks the authority for its verdict on everything awaiting a decision, about every fifteen minutes.Administrator starts it once
A connection to your country's authorityEvery country files differently. The connection to a specific authority is supplied by an extension package installed alongside REDA Financials. The core app provides the framework, the audit trail and the workflow.Installed with your implementation partner

What happens when an invoice is posted

Assuming the entity is configured and the connection is in place, this is the sequence — none of it requires anyone to leave REDA Financials or re-key anything into a government portal.

  1. A user posts the sales invoice, exactly as they always have. Nothing about posting changes.
  2. An E-Invoice Trail is created for that invoice, automatically. This happens after the invoice is safely saved, deliberately: a problem reaching the tax authority can never undo or block the posting itself. Your books are never held hostage to a government service being slow.
  3. The Trail is either released immediately or held as a draft, depending on how you configured the entity. Automatic release suits high-volume invoicing; holding suits businesses that want a person to check before filing.
  4. The document is transmitted and the authority acknowledges receipt. The Trail moves to Submitted. At this point the authority has the invoice but has not yet ruled on it.
  5. The status poll collects the verdict — the invoice becomes Accepted (and gains its fiscal identifier) or Rejected (with the authority's reason recorded).
  6. The invoice itself shows the outcome. Two read-only fields on the Sales Invoice — E-Invoice Status and E-Invoice UUID — let anyone see the position without opening the Trail.
Steps 4 and 5 do not happen by themselves. The status poll is a scheduled job, and a scheduled job cannot be delivered inside an installed package — every org must start its own. If nobody starts it, invoices posted one at a time are filed and then sit at Submitted for ever, invoices posted in bulk are never transmitted at all, and there is no error and no explanation. See the E-Invoice Status Poll card.

The statuses, and what each one is telling you

StatusMeaningDoes it need a person?
DraftA Trail exists but has not been released for filing. Normal when the entity files manually.Yes — someone must release it
Ready to Send / QueuedReleased and in line for transmission.No
SubmittedThe authority has it and has acknowledged receipt; no verdict yet.No — the poll handles it
AcceptedApproved. The invoice is legally valid and carries its fiscal identifier.No — this is the finish line
RejectedThe authority refused the document and said why. Common causes are a customer tax identifier that does not match the authority's register, or a total it disputes.Yes — correct and reissue
ErrorThe exchange itself failed — it never reached the authority, or the reply never arrived. Different from a rejection.Yes — fix and resubmit
CancelledThe document was withdrawn.No
Rejected and Error are not the same problem. A rejection is the authority's decision about the invoice's content — the system worked. An error means the conversation broke down. Polling again will resolve neither; both need a person, but they need different people doing different things.

Why a filed invoice cannot be unposted

Once an invoice has been submitted, REDA Financials will not let you unpost or change it. This is not a system restriction that can be configured away — the tax authority already holds that document, and altering your copy would put your books out of step with the government's record.

The correct remedy is the same one accountants have always used: issue a credit memo to reverse the original, then raise a corrected invoice. The corrected invoice is filed in its own right, so the authority's record and yours stay in step and the correction is fully traceable — which is exactly what an audit needs.

Invoices you do not want filed

Some invoices should never go to the authority — an internal charge between your own entities, a test document, a transaction outside the scope of the mandate. A Skip E-Invoicing checkbox on the Sales Invoice excludes that one invoice completely: no Trail is created and nothing is transmitted.

The checkbox needs one setup step before anyone can tick it. Sales Invoice uses a custom entry form, so putting Skip E-Invoicing on the page layout makes it visible but not fillable. To let users set it, an administrator must also add it to the Sales Invoice Interface field set — Setup → Object Manager → Sales Invoice → Field Sets → Interface → drag Skip E-Invoicing into the selected box → Save. It ships available but not selected, because most organisations never file electronically.

Who needs to do what

RoleWhat they do
AdministratorCreates the E-Invoice Setup per entity, schedules the status poll, places the new fields on layouts, grants field-level security, and adds Skip E-Invoicing to the Interface field set. Once, at go-live.
Accounts ReceivablePosts invoices as normal. Watches E-Invoice Status on the invoice, ticks Skip E-Invoicing where an invoice is out of scope, and reissues anything the authority rejects.
Controller / auditReads the E-Invoice Trails as evidence of filing, and monitors the counts on the Operations card for a queue that has stopped moving.

Where to go next

Frequently asked questions

No. With no E-Invoice Setup record, nothing happens: no Trails are created, the Operations card tells you there is nothing configured, and invoicing behaves exactly as before. The feature is inert until an entity is set up for it.

Yes — configuration is per entity. Create an E-Invoice Setup only for the entities whose country requires it; the rest are unaffected.

No. The Trail is created after the invoice is committed, in a separate step, precisely so that a slow or unavailable tax authority cannot delay or fail a posting.

The invoice stays at Submitted and appears in the "Awaiting authority response" count on the Operations card. If a single document sits there while others clear, open its Trail and check whether an acknowledgement was ever recorded; if not, resubmit it.

Not in this release. Electronic filing currently covers sales documents.

The E-Invoice Trail. There is one per invoice and it records what was sent, what the authority replied, when, and the fiscal identifier issued — which is normally exactly what an auditor asks to see.