E-invoicing & Clearance
E-invoicing turns invoicing into an integration. The invoice is no longer finished when you print it, and the project has to be designed around that.
End-to-end e-invoicing enablement for ZATCA Phase 2 (KSA), UBL 2.1, PEPPOL, Italy SDI, and India IRN, with QR codes, XML generation, and clearance workflows.
The change that catches teams out is not the file format. It is that an external system now has an opinion about your invoice. Something can be rejected, held, or accepted only after a delay, which means invoicing acquires states it never had before, and somebody has to own the ones that go wrong.
So the design work is mostly about failure handling and data readiness. Master data that was good enough for a printed invoice is often not good enough to pass validation, and that is discovered in bulk on the first day unless it is checked in advance. We check first, fix at source, then build.
As with all compliance work, the requirement comes from your accountant, auditor or adviser and from the official documentation, not from us. The specifics for each market are on the country pages. This page is about how the project runs.
What is included
- โ ZATCA Phase 2 (KSA) clearance
- โ UBL 2.1 XML generation
- โ PEPPOL network integration
- โ Italy SDI, India IRN, Egypt ETA
- โ QR code signing (ECDSA)
- โ Clearance & reporting workflows
- โ Archive-ready long-term storage
- โ Audit trail & re-submission
How the engagement runs
- 1
Requirement and readiness
Confirm what has to be produced and whether your data can produce it.
- Requirement confirmed in writing by your adviser and against the official documentation
- Profile your master data against the fields the output needs, and count the gaps
- Establish which transaction types are in scope and which are handled differently
- Identify who on your side owns a rejected document, since that role usually does not exist yet
You end up with: A confirmed requirement, a data gap report with counts, and a named owner for exceptions.
- 2
Data remediation
Fix the master data before it fails validation in front of customers.
- Bulk correction at source for the fields the output requires
- Validation added at entry so the same gaps do not reappear next month
- Historical records assessed: which have to be corrected and which can stay as they are
- A repeatable check that can be run again before go-live
You end up with: Clean master data and an entry-time check that keeps it clean.
- 3
Build and sandbox testing
Produce and submit real documents in a test environment before any of it counts.
- Generate the output for each in-scope document type and validate it against the published schema
- Connect to the test environment and submit, then read what comes back carefully
- Handle the response states properly: accepted, accepted with warnings, rejected, and pending
- Store the identifiers and responses against the document, so status is visible where users work
- Test the awkward cases: credit notes, corrections, foreign currency, discounts, mixed treatments
You end up with: Successful test submissions covering every in-scope document type, with evidence.
- 4
Exception and archive design
Decide what happens on a bad day, before there is one.
- Queue and retry for transient failures, with a dead-letter path and an alert for the rest
- A clear work list of documents needing human attention, owned by a named role
- Archiving of the submitted output and the responses in a form that survives system changes
- Reconciliation between what was issued in the ledger and what was submitted
You end up with: A working exception process, an archive, and a scheduled reconciliation.
- 5
Go-live and monitoring
Switch over with someone watching, then keep watching.
- Phase by document type or by entity where the process allows it
- Daily review of the exception list during the first period
- Alerting on submission failures and on queue age, since these fail quietly
- Train the finance team on the exception handling, not just on issuing an invoice
You end up with: Live submission with monitoring, an exception routine and a trained team.
What you need to provide
The schedule slips on these more often than on anything technical.
- โ Your adviser, to confirm the requirement in writing and to review the output
- โ Registration details, credentials and any certificates the process needs, obtained by you
- โ Master data ownership on your side, to approve bulk corrections
- โ A named person who will own rejected and pending documents daily
- โ Sample documents your customers already accept, and any format they insist on
- โ A decision on how long submitted output and responses must be retained
Decisions you will be asked to make
Who owns the exception list
Rejections need a human every day. If that is nobody, the list grows until it is a project. This role has to be named before go-live, not discovered after it.
Phase or switch everything at once
Phasing by document type or entity keeps the first week small enough to manage. It costs a longer period of running two routines, and that is a real cost worth weighing honestly.
How much historical data to correct
Correcting everything is thorough and slow. Correcting only what will be issued going forward is faster and leaves older records inconsistent. This is a reporting and audit decision, so your adviser should make it.
Where the archive lives
The archive has to outlive the current system and stay readable by someone who was not there when it was created. That is an infrastructure decision with a long horizon, and it belongs in the design rather than at the end.
Where this goes wrong
The failure modes we plan around, and what the plan does about each one.
Data quality discovered on go-live day
Master data that was fine for a printed invoice fails validation in bulk, and it happens in front of customers. Data is profiled and corrected before the build, not after the first rejection.
No owner for rejections
Rejected documents pile up because they belong to everybody. A named role with a daily routine is the difference between a work list and a backlog.
Only the simple invoice tested
Credit notes, corrections, foreign currency and mixed treatments behave differently and are exactly what breaks in month two. Every in-scope document type is tested in the sandbox.
Submission failures that are invisible
A failed submission with no alert becomes a compliance problem weeks later. Failures alert, and a reconciliation compares what was issued against what was submitted.
Archive as an afterthought
Storing output only inside the live database ties your records to the life of that database. The archive is designed to be portable and readable independently.
Training that stops at issuing an invoice
The new skill is handling the exception, not pressing send. Training targets the exception routine, because that is the part that is genuinely new.
Not included
Stated up front so the proposal has no soft edges.
- ร Determining whether and when the requirement applies to you: that is your adviser's call
- ร Obtaining registrations, credentials or certificates on your behalf
- ร Fees charged by any authority, agent, certified provider or service
- ร Filing, submitting or correcting historical periods for you
- ร Legal or tax opinions
- ร Guaranteeing acceptance by a system whose validation rules are outside our control
How this is priced
Quoted per entity and per document type in scope, after the data readiness check, because a quote written before anyone has looked at the master data is a guess. Ongoing monitoring and change handling belong in a support agreement.
See the published bands โModules that come up on this work
Ready-built modules from our own catalogue. Where one of these covers the requirement, installing it beats writing it.
Documents DMS with Folder Permissions and Versioning
Document manager on top of attachments: folder level access rights, file versions with restore, tokenised upload requests, PDF split and merge.
Why here: Submitted output and responses have to be findable years later, with versions, by someone who was not there.
Productivity/DocumentsAudit Log & Access Tracking
Track who created, changed or deleted records - full audit trail with field-level history and access-rights tracking.
Why here: Reviewers ask who changed a document before it was submitted. Having the answer without a database query saves hours.
ProductivityImport / Export Power Tools
Powerful data import & export for any model - CSV / XLSX / JSON, upsert, scheduled exports, templates and error logs.
Why here: The data remediation phase is a bulk correction job, and doing it by hand is where these projects lose weeks.
ProductivityDuplicate Customer Warning
Warn when a new contact has the same name or email as an existing one.
Why here: Duplicate customer records are a frequent cause of validation problems, and catching them at creation is the cheap fix.
ContactsPartner Auto Reference
Automatically fill a contact's Reference code from a sequence when it is left blank.
Why here: Consistent partner references make reconciliation between issued and submitted documents far easier to automate.
ContactsWhere we deliver this
The scheme, format and timetable for each market are on the country pages, which are sourced and reviewed separately from this one.
E-invoicing & Clearance: common questions
What is different about invoicing once this is live?
The invoice is no longer finished when it is printed. It acquires states it never had before: submitted, accepted, rejected, pending. Those states need to be visible where your team works, and somebody has to own the ones that are not accepted. That role is the part most projects underestimate.
Which countries and formats do you support?
Our country pages list what applies in each market and are maintained separately from this page. The delivery approach is the same regardless of destination: confirm the requirement with your adviser, profile the data, test in the sandbox, design the failure handling, then go live with monitoring.
What is the most common cause of delay?
Master data, by a wide margin. Records that were perfectly adequate for a printed document turn out to be missing fields the output requires, and there are usually more of them than anyone expects. That is why readiness is profiled before the build starts.
What happens if a document is rejected?
It goes on an exception list with the reason attached, and a named person works that list daily. Transient failures retry automatically with backoff. Anything needing a decision waits for a human rather than being silently dropped.
How long do we have to keep the output?
Your adviser sets the retention period. What we handle is making sure the submitted output and the responses are archived in a portable form that stays readable independently of the current system, since retention periods usually outlast software.
Can this be added to an existing Odoo instance?
Yes, and most of these projects are exactly that. It starts with the same data readiness check, which on an established instance with years of history typically finds more to fix than on a new one.
Read next
Odoo Localization
Country-specific compliance out of the box.
Odoo Implementation
End-to-end Odoo deployment, from discovery to go-live.
Odoo Integration
Connect Odoo with your stack and third-party APIs.
Odoo Support & Maintenance
24/7 monitoring, bug fixes, performance tuning.
Odoo Health Audit
Deep technical + functional audit of your instance.
Tell us what you are trying to fix
A 30-minute call is usually enough to tell you whether this is a small piece of work or a project, and to say so before anyone writes a proposal.