E-invoicing data readiness in Odoo

Connecting Odoo to the tax authority's e-invoicing platform looks like a connectivity project: configure, test, go live. In most implementations the harder half is not the connection but the data Odoo sends through it. The platform builds on what the system already holds, so a document can pass through the connection and still be rejected, or need manual correction, because the seller record, the customer, the item or the default tax was wrong. This article separates what has to be true of the data before connecting from the act of connecting. Detailed requirements belong to the competent authority and the applicable regulations, they change, and the current official specification must be checked before any decision. For the wider picture see our Odoo e-invoicing guide.

Readiness before connectivity: two separate pieces of work

Having e-invoice-ready data and having a working connection to the authority's platform are two separate pieces of work, planned and tested independently. Readiness is mostly configuration and master data inside Odoo Accounting: registration fields, customer tax numbers, item taxes, sequences, credit notes. Connectivity is credentials, endpoints, transport, retries and monitoring. One can be finished while the other is not, so the two scopes should be separated in the proposal and in the tracking, and any duration mentioned is a planning range until a written scope is agreed, never a commitment.

The seller's registration data

• The legal name exactly as registered, without internal shorthand the team is used to.
• The registered tax number, matching the official record field for field.
• The national address and branch details that may appear on the document.
• Contact data where the document requires it.
• Which document type applies to a given sale.

Odoo prints what has been stored; it does not compare that with the official record on its own. One different field produces a document that does not match the record, and this usually surfaces during review rather than at entry. The check described here is not a legal audit; it is a structured comparison that makes the differences visible while they are still inexpensive to fix. Responsibility for the final data rests with the client, because the competent authority is the source of the requirements and the body that updates them.

Customer records and the tax number

Consumer sales normally use the simplified document. Transactions that require a tax invoice need a correct customer tax number stored on the customer record. The repeating defect is that the field is not required in Odoo, so a user types a placeholder or issues the wrong document type, and the problem surfaces only on reissue. Practically: make the field mandatory in the context that needs it, clean the recurring-customer list, decide who asks the customer and when, and block invented or derived numbers. A missing tax number is rarely an Odoo defect; it is a process question that needs a clear answer before the invoice is issued.

Items and default taxes

Every product carries a default tax that is pulled into the invoice line. The common defect is an item with no default tax or with a wrong one, so the team issues a full invoice and then repairs the lines by hand. Mixed rates on one invoice are legitimate when the item mix requires it, as long as the mapping between each item and its tax treatment is explicit. What to verify: tax groups, computation at line level, a documented list of exempt or specially treated items, and confirmation of the right treatment for each item family with the client's responsible accountant.

Numbering, sequences and credit notes

Decisions to settle before go-live:

1. One sequence per document type, and no mixing of tax and simplified documents in a single sequence.
2. No manual numbering and no continuing a sequence outside Odoo for any reason.
3. Checking for gaps or duplicates before connecting, and resolving them.
4. Tying every credit note to the original invoice it corrects.
5. Testing cancellation and correction, and reviewing the effect on sequences and reports.
6. Writing the policy down in a short note that accounting and sales both know.

A manual or duplicated sequence is a problem because it breaks traceability and turns matching issued documents against the system into guesswork. A credit note is not a new invoice; it is a correction tied to an original, and that link must stay visible in the system and in the archive.

Invoice fields, the QR code, archiving and environments

The document has to carry the seller details and tax number, the customer details and tax number where required, the issue date, the invoice number, line descriptions, quantities, prices and taxes, the totals and the tax amount, plus the QR code and the identifier. The QR code carries a short machine-readable summary of the document data, and the identifier is a unique reference for the invoice; their exact structure is set by the official specification issued by the competent authority, which is the reference whenever a question arises. Archiving comes after issue: a stored copy that can be retrieved on request, permissions that define who may view and who may amend, and a test environment kept apart from production so that real data is not used in experiments and testing does not disturb the production sequence. Before connecting, review a sample of real invoices line by line; that work sits at the centre of e-invoicing readiness, not in the technical setup alone.

What we do not guarantee

• We do not guarantee that any document is accepted by the competent authority; acceptance is the authority's decision alone.
• We do not give a legal or tax ruling, nor a binding interpretation of the regulations.
• We do not guarantee ongoing alignment with a specification that can change; meeting the current official specification is the client's responsibility.
• We do not commit to a price or a duration before a written scope analysis; any time estimate is a planning range only.
• We do not guarantee a commercial outcome or a search ranking.
• We do not issue a certificate or an accreditation, and we do not represent any regulatory body.