Two months after the reform took effect on 1 September 2026, the question is no longer whether invoice flows get through, but how your ERP behaves when they don’t. Our first-month review described the early friction points. This article takes a different angle: configuration. Which data errors produce rejections, how to bring lifecycle statuses back into the ERP, what to transmit for e-reporting, and what all of it means for accounting and cash flow.
A note on method: to our knowledge, the French tax authority (DGFiP) had not published consolidated rejection statistics as of 13 November 2026. No rejection rate is quoted here. Where a source is missing or two sources disagree, we say so rather than fill the gap.
Where Things Stand: What Is Confirmed
Timeline. Since 1 September 2026, all VAT-registered businesses must be able to receive electronic invoices through an accredited platform. Issuing and e-reporting currently apply to large companies and mid-caps. SMEs and micro-businesses follow a year later, on 1 September 2027 (La Poste, e-reporting: which data to transmit).
Statuses. The AFNOR XP Z12-012 standard requires four mandatory statuses that every accredited platform must handle: deposited, rejected, refused, paid. Any additional statuses are optional (swim.legal, e-invoice lifecycle, accessed 13 November 2026).
Rejection codes. A regularly updated summary by Compta Online (published 14 April 2026, modified 9 November 2026) groups anomalies into six families: technical rejections, routing and addressing, calculations and amounts, VAT and compliance, business refusals, commercial disputes. It lists 13 codes that justify a “refused” status and 7 corrective-action codes (compta-online.com).
What we could not verify. The DGFiP reference pages on e-reporting (transaction data, payment data, frequency table) are published on impots.gouv.fr as PDFs whose content we could not extract at the time of writing. The detailed frequencies below therefore rely on secondary sources that do not fully agree: confirm them on the official page before configuring anything.
Top Rejection Causes and How to Fix Them in the ERP
Earlier articles already covered identifier and mandatory-mention errors. The table below ties each cause to the ERP data that produces it, which is what matters to an IT director. The code families come from the Compta Online summary; the relative frequency of each cause is not publicly documented and is therefore not shown.
| Cause (code family) | Symptom in the ERP | Configuration fix |
|---|---|---|
Unknown recipient or wrong address (routing: DEST_INC, ADR_ERR, ROUTAGE_ERR) | Invoice “rejected” or blocked at issuance even though the document is correct | Store the SIREN (9 digits) and establishment SIRET in dedicated, validated fields; fill in the customer’s e-invoicing address; query the directory before the first send |
Calculation mismatch (CALCUL_ERR, MONTANTTOTAL_ERR) | Gross total differs from the sum of lines by one cent | Align the ERP rounding rule with the format’s (per line or global, one documented choice); test discounts and credit notes |
VAT rate or regime (TX_TVA_ERR, NON_CONFORME) | Rate inconsistent with the exemption or reverse-charge reason | Codify exemption reasons in the VAT table; forbid free-text entry; make the reverse-charge mention mandatory in the XML flow, not only in the PDF |
Order or contract reference (CMD_ERR, REF_CT_ABSENT, CONTRAT_TERM) | Customer refusal for lack of an order or contract number | Make the purchase order number mandatory at invoice validation for customers who require it; check contract validity |
Duplicate (DOUBLON, DOUBLE_FACT) | Invoice resent after a rejection and refused as a duplicate | Never re-key the same document: issue a new invoice or a credit note according to the action code received |
Encoding and schema (IRR_*, REJ_* families) | Corrupted accented characters, XML not matching the schema | Export in UTF-8; validate the XML with the platform’s validator before transmission |
The common thread: a rejection is almost always a badly maintained master-data item (customer record, VAT table, rounding rule), not a transmission incident. Fixing it at the source avoids reprocessing documents one by one. If a batch of rejections comes back with the same cause, the partner record or the parameter needs review, not the invoice.
Lifecycle Statuses: Bringing Them into the ERP and Using Them
Four mandatory statuses, four distinct uses. The definitions below follow the swim.legal summary.
- Deposited: the invoice has been submitted to the issuer’s platform. In the ERP, this is the receipt that lets you say “issued” with a dated proof.
- Rejected: the invoice failed technical or regulatory checks. It is deemed not issued: it has no legal existence and the payment term does not start running.
- Refused: the customer disputes it on substantive grounds. The invoice circulated, but it calls for a corrective invoice or a credit note.
- Paid: the supplier declares payment received. This status matters for services, where VAT becomes due on payment.
How to use them. Three concrete configurations come up repeatedly:
- A status field on the accounting document, fed by the platform’s API or return file, with a timestamp for each change. Without it, the aged receivables report overstates receivables: a rejected invoice is not a due receivable.
- Work queues by status. Rejected invoices go to billing (data fix, reissue), refused ones to sales or collections (dispute, credit note), each with a named owner and an internal deadline.
- A “paid” status issued by the ERP at reconciliation, for the operations concerned. This is the only mandatory status the supplier must produce itself: it assumes bank reconciliation and matching are up to date when the declaration is made.
Optional statuses (taken in charge, approved, disputed, suspended, payment transmitted) are not mandatory. They mainly matter on the buyer side: “approved” feeds the approval workflow, “disputed” stops automatic dunning. Before enabling them, check which ones your platform actually offers.
Watch out for a common blind spot: an interface that silently drops a status return leaves the ERP believing an invoice was issued when it was rejected. ERP interface monitoring must therefore cover the return flow as much as the outbound one.
E-Reporting: What to Transmit, Who Transmits, and How Often
E-reporting covers what the e-invoice does not: sales to consumers (B2C), international transactions, certain B2B services, and payment data. There is no revenue threshold: every VAT-registered business falls within scope at its due date (La Poste).
Two separate flows.
- Transaction data: for each period, aggregated data (net amount, VAT rates applied) on B2C sales and international transactions (Hayot Expertise).
- Payment data: required for operations whose VAT is due on payment, typically services.
Who. The company remains responsible for transmission, through its accredited platform. Delegating to an accounting firm is possible, but responsibility stays with the company (same Hayot source).
How often: sources disagree. La Poste indicates transmission within 10 days after the period, with a rhythm that depends on the VAT regime (several times a month for the normal monthly regime, monthly for the simplified or quarterly regime, every two months for the VAT-exempt franchise). Hayot Expertise gives a similar rhythm but different deadlines for the simplified regime and the franchise (around the 25th to 30th of the following month). Both agree on the principle: frequency depends on the VAT regime, not on company size. We therefore do not retain any specific deadline: the DGFiP’s official table of frequencies and deadlines is authoritative.
Penalty. According to La Poste, €500 per missed transmission, capped at €15,000 per year, with regularisation possible within 30 days without a fine for a first offence. These elements restate Article 1788 D of the French Tax Code (CGI), already cited in our day-25 review; check them against the text in force.
On the ERP side. Two preliminary checks: tag every sale by flow (B2B invoice, B2C e-reporting, international e-reporting) and make sure the VAT-rate breakdown of the entries is usable. Tills, web shops and payment gateways often feed the ERP summary entries: if the per-rate detail is lost on import, the aggregate transmitted will be wrong.
Accounting and Cash Flow Impacts
Terms. A rejected invoice is deemed not issued. The start of the payment term (and thus of dunning) is that of the accepted invoice, not of the attempt. For cash flow, every rejection corrected late pushes collection back by the same amount.
Credit notes. A refused invoice is corrected with a credit note and a new invoice, or a corrective invoice. The ERP must link the credit note to the original invoice (mandatory reference) and VAT accounting must follow: the credit note is itself a document that goes through the platform and can be rejected.
Posting. On the customer side, posting on receipt of the invoice “made available” rather than on approval can create payables for invoices that will later be refused. Decide, by flow type, at which status the entry is posted, and document it for audit. The rules on the ERP audit trail (French-language article) apply to statuses as much as to documents.
Reconciliation. Plan a monthly reconciliation statement: invoices posted, invoices deposited, rejected or refused invoices not yet handled, paid invoices declared. Any unexplained gap must be justified before closing. The ERP regulatory calendar for January 2027 lists the deadlines that come on top.
30-Day Action Plan
Week 1, measure.
- Extract from the accredited platform the list of rejections and refusals since 1 September, with the reason code
- Classify by code family and by data cause (partner record, VAT, rounding, reference)
Week 2, fix at the source.
- Clean up customer records: 9-digit SIREN, establishment SIRET, e-invoicing address
- Lock exemption and reverse-charge reasons in the VAT table
- Make the purchase order number mandatory for customers who require it
- Freeze the rounding rule and test it with discounts and credit notes
Week 3, wire up the statuses.
- Check that the four mandatory statuses flow back into the ERP with timestamps
- Create the rejected and refused work queues, each with an owner
- Exclude rejected invoices from due aged receivables
- Monitor the status return flow (alert if no return within a defined time)
Week 4, prepare e-reporting.
- Confirm on impots.gouv.fr the frequency applicable to your VAT regime
- Tag B2C and international sales and check the breakdown by rate
- Define who transmits (in-house or accounting firm) and who approves
- Set up the monthly reconciliation statement before the next close
To follow DGFiP clarifications and changes to platform standards, subscribe to the ERP regulatory watch newsletter.
