FatturaPA on Odoo: 2026 Implementation Guide for Italy

Italian electronic invoicing — FatturaPA — has been mandatory for B2B and B2C since January 2019. By now the patterns are well-tested. Yet I still see foreign-owned operations setting up Italian subsidiaries with bolt-on third-party invoicing tools or misconfigured Odoo flows that produce avoidable rejections at the SDI portal.

This post is for teams operating Italian entities (or planning to) on Odoo. The native Italian localization is good; here’s how to use it well.

A 30-second primer on FatturaPA

FatturaPA is the standardized XML format for Italian electronic invoices. Every invoice — B2B, B2C, and to the Public Administration — must:

1. Be generated as a FatturaPA XML document
2. Be submitted to the SDI (Sistema di Interscambio), the government’s exchange portal
3. Be delivered to the recipient via SDI (recipient’s PEC email or codice destinatario)
4. Be retained for 10 years per Italian regulatory requirement

Three categories of invoice with slightly different rules:

• FatturaPA B2B/B2C — between businesses or to consumers; recipient identified by codice destinatario or PEC
• FatturaPA PA — to Italian public administration; recipient identified by codice univoco IPA
• Self-invoice (autofattura) — for reverse-charge VAT scenarios; the buyer issues to themselves

Each category has subtle XML differences. Odoo’s Italian localization handles all three but you have to configure the customer master correctly.

Pitfall 1: codice destinatario vs. PEC

Every Italian customer must have a delivery address in SDI’s system, identified by:

• Codice destinatario (7-character code) — used by businesses with their own SDI integration
• PEC (certified email address) — used by businesses without their own SDI integration
• 0000000 — default fallback meaning “deliver to the recipient’s PEC mailbox via SDI”

The customer master in Odoo has fields for both. The wrong configuration results in delivery to the wrong destination — invoices ostensibly accepted by SDI but never reaching the customer’s accounting system.

The right way to ask: during customer onboarding, ask explicitly “what’s your SDI delivery preference: codice destinatario or PEC?” and capture both fields. If unknown, default to 0000000 and capture the PEC.

Pitfall 2: VAT-number validation

Italian VAT numbers (Partita IVA) have a checksum. Odoo’s Italian localization validates the checksum on customer-master save, which catches the most common typo. But non-Italian VAT numbers (for cross-border B2B customers under reverse-charge VAT) need different validation — and Odoo’s default config sometimes treats them as Italian, generating spurious checksum errors.

For cross-border customers: ensure their country is set correctly before entering the VAT number. The VAT-validation logic uses the country to pick the right validation rule.

Pitfall 3: Payment-method codes

FatturaPA requires specific payment-method codes (MP01 cash, MP02 check, MP05 bank transfer, etc.). Odoo’s Italian localization maps standard payment methods to FatturaPA codes, but custom payment methods (often added by foreign-owned operations to match their global accounting standards) don’t auto-map.

Default fix: map custom payment methods to FatturaPA codes during initial setup. Don’t wait for the first rejection.

Pitfall 4: Reverse-charge VAT handling

Reverse-charge VAT — where the buyer reports VAT instead of the seller — applies to specific transaction types (cross-border EU B2B, certain construction services, scrap metals, electronics over threshold). FatturaPA needs the correct natura code (N6.1–N6.9) on the invoice, plus the buyer needs to issue an autofattura to themselves.

Odoo’s tax codes for reverse-charge are pre-configured in the Italian localization but require specific tax mappings on customer/vendor masters. Misconfigured reverse-charge results in invoices that pass SDI but fail VAT-return reconciliation downstream.

This is where I see most accounting-team frustration: the rejection happens months after the invoice was issued, and the root cause is a customer-master configuration error from the implementation phase. Get the tax mappings right at go-live.

Pitfall 5: SDI authentication and certificate management

FatturaPA submissions require SDI authentication via either:

• PEC — submit invoices via certified email
• Web service (SOAP) — direct API submission with X.509 certificate
• Cooperative gateway — submit through an intermediary (your accountant’s portal)

For mid-sized operations, the cooperative gateway is the right choice — pay a small fee to an intermediary (Aruba, InfoCert, etc.) to handle the SDI authentication and provide a clean API to Odoo. Your IT team doesn’t have to manage the X.509 certificate or the PEC email infrastructure.

For larger operations or those with their own IT capacity, web-service submission with a managed X.509 certificate is more robust long-term. Either way, don’t put off cert management — expired certs cause submission failures that look like SDI being down.

What native Odoo handles well

For most Italian operations, the native Odoo localization (configured correctly) handles:

• FatturaPA XML generation per invoice
• SDI submission via cooperative gateway or direct
• Status tracking (submitted, accepted, rejected) with auto-retry for transient failures
• Storno (credit-note) flows with correct linkage to original invoices
• 10-year archive retention with audit-search support
• VAT registers (registro IVA acquisti, vendite, corrispettivi) for monthly/quarterly returns

If you’re configured correctly, you don’t need any third-party tool. Bolt-on tools usually exist because someone fought through a misconfiguration in the past and reached for an external fix. Fix the configuration first.

A 2026 watchlist

Two regulatory changes Italian operations should track:

1. EU VAT in the Digital Age (ViDA) proposals — partial alignment with FatturaPA expected over 2026–2028, but specifics are still in legislative review.
2. SDI capacity upgrades for high-volume submitters announced for late 2026 — minor architectural change for very large operators only.

Neither requires immediate action; mention them at quarterly business reviews.

Final recommendation

If you’re operating an Italian entity on Odoo:

1. Use the native Italian localization. Skip bolt-on tools.
2. Audit customer master configuration — codice destinatario, PEC, country, VAT number, payment-method codes — at go-live and quarterly thereafter.
3. Use a cooperative gateway unless you have IT capacity to manage X.509 certs.
4. Fix reverse-charge mappings at go-live rather than after the first rejection.
5. Run quarterly VAT-register reconciliation to catch configuration drift before the audit does.

If you want help configuring Italian e-invoicing on Odoo — or evaluating an existing setup — book a scoping call with our Milan office via the contact page. The Italian e-invoicing patterns we use are reusable across newer e-invoicing regimes (KSA ZATCA, Brazil NFe, Mexico CFDI), which is most of what we’re building these days.