Italy FatturaPA (SdI)

Key Features

Dedicated Frappe app with its own module, DocTypes, and repo — installed via `bench get-app` and `bench --site install-app`, not custom fields bolted onto Sales Invoice

`Italy E-Invoice` submittable DocType per transmission, holding the generated XML, progressivo di invio, `IdentificativoSdI`, current status, and a child table of every notification received

`hooks.py` `doc_events` on Sales Invoice `on_submit` builds the `FatturaElettronica` payload from Company, Customer, and Sales Invoice Item master data — no re-keying into a portal

Local FatturaPA XSD validation before transmission, so schema errors are caught in ERPNext instead of returning hours later as an SdI `NotificaScarto`

`Natura` and `TipoDocumento` mapping DocType resolved against your existing Item Tax Templates and Tax Categories, covering exempt, non imponibile, and reverse-charge lines

Customer-side `CodiceDestinatario` and PEC fields with validation, plus partita IVA / codice fiscale checks and B2C fallback handling

Queued transmission via Frappe background jobs to your chosen channel — certified intermediary REST API, SFTP drop, or PEC — with retry and backoff rather than a blocking HTTP call on submit

Scheduler event that polls for and ingests ricevute, parsing RC, NS, MC, DT/AT and PA NE outcomes and translating SdI error codes into readable causes on the invoice

Rejection correction workflow: amend source data, regenerate under a fresh progressivo, resend — with the original, rejection, correction and delivery chain on one timeline

Human-readable Print Format rendered from the same posting that produces the machine XML, so the customer copy and the SdI copy can never drift apart

Withholding (`ritenuta`), bollo, cassa previdenziale, DDT references and `DatiOrdineAcquisto` links carried through from ERPNext where the source data exists

Compliant archiving: XML sent and every notification received stored as immutable File records with Frappe version history, comments, and a defensible audit trail

Whitelisted REST API methods for transmission status, resend, and outcome retrieval, guarded by a dedicated Role and Role Profile (view vs. resend vs. override)

Client script on Sales Invoice surfacing live SdI status inline, plus a pending / delivered / rejected / deadline-exceeded report so month-end close is exception-driven

Built and tested against Frappe/ERPNext v15 and v16, with migration-safe patches so `bench migrate` behaves predictably across upgrades

Built to order, done for you

No DIY setup — a working app, built, installed and supported by ECOSIRE.

You order

Start with a one-time build price. We scope it with you at kickoff.

We build & install

ECOSIRE builds, configures and installs it on your ERPNext.

Go live + support

You go live in about 2–4 weeks, with a post-launch support window.

About this Product

Italian e-invoicing is not a PDF problem, it is a state-machine problem. Every B2B, B2C, and PA invoice has to leave your books as a FatturaPA XML, pass through the Sistema di Interscambio, and then come back as a sequence of ricevute — RC delivery receipt, NS rejection, MC non-delivery, DT/AT deadline notices, and for PA invoices the NE acceptance or refusal from the receiving administration. ERPNext core stops well before that line. Out of the box it gives you a Sales Invoice, an Italian Chart of Accounts, and Item Tax Templates; it has no FatturaPA schema builder, no TipoDocumento or Natura coding, no notion of a Codice Destinatario or a PEC address on Customer, no transmission channel, and no way to represent an invoice that is legally posted in your ledger but rejected by SdI five hours later. Finance teams end up re-keying invoices into an intermediary's web portal and reconciling two systems by hand at month end.

We build a proper Frappe app — its own repo, its own module, its own DocTypes — rather than a pile of custom fields on Sales Invoice. The core is an Italy E-Invoice submittable DocType holding one transmission per invoice: the generated XML file, the progressivo di invio, the SdI identifier (IdentificativoSdI), the current status, and a child table of every notification received with its timestamp and raw payload. A hooks.py doc_events handler on Sales Invoice on_submit builds the FatturaElettronica payload from ERPNext master data — Company as CedentePrestatore (partita IVA, regime fiscale, REA, address), Customer as CessionarioCommittente (partita IVA or codice fiscale, CodiceDestinatario or PEC), and each Sales Invoice Item as a DettaglioLinee line with its AliquotaIVA and, for exempt or reverse-charge lines, the Natura code resolved from a mapping DocType you maintain against your existing Item Tax Templates. Withholding (ritenuta), bollo, cassa previdenziale, DDT references, and DatiOrdineAcquisto links to the originating Sales Order are carried through where that data exists in ERPNext.

Transmission is queued, never synchronous. Submitting the Italy E-Invoice enqueues a background job that validates against the FatturaPA XSD locally first — so schema errors surface in your ERP, not as an NS three hours later — then delivers through your chosen channel: a certified intermediary's REST API, an SFTP drop, or PEC, whichever your accountant already uses. A scheduler event polls for and ingests notifications, parses each RicevutaConsegna or NotificaScarto, and writes the outcome onto the transmission with SdI error codes translated into readable text. A rejection does not silently die: it opens a correction cycle that lets finance amend the source data, regenerate a new XML under a fresh progressivo, and resend, with the full chain — original, rejection reason, correction, resend, final delivery — visible on one timeline. Human-readable output comes from the same posting: a Print Format renders the invoice for the customer while the machine format goes to SdI, so the two can never diverge. Everything is exposed through whitelisted methods on the Frappe REST API, guarded by a dedicated Role and Role Profile so an AR clerk can view transmissions while only a Finance Manager can resend or override.

Archiving is treated as a first-class requirement rather than an afterthought. The XML sent, every notification received, and the transmission metadata are stored as immutable File records attached to the transmission, with the version chain preserved and Frappe's document versioning and comment trail giving you a defensible audit history. A report and dashboard show what is pending, delivered, rejected, or past its SdI deadline, so the close is driven by exceptions instead of a spreadsheet. Because it is an ordinary Frappe app installed with bench get-app and bench --site install-app, it moves with your bench and does not fight future ERPNext releases.

This is build-to-order, and we are straightforward about what that means: there is no instant download. You request a quotation, we run a scoping call, and we confirm your ERPNext version, your invoice types (B2B, B2C, PA, self-billing, reverse charge), the transmission channel you already hold a contract for, and the volume you send. From confirmed scope, typical delivery is two to four weeks. You get the app built against your version, installed and configured on staging first, UAT run with your own invoices against the SdI test environment where your provider offers one, then go-live with a rollback plan, followed by a support window and the full git repository handed to you.

What you get

Installable source code of the app built specifically against your Frappe/ERPNext version (v15 or v16) and your site's existing customizations

Installation and configuration on your bench — app install, transmission channel credentials, Natura/TipoDocumento mapping, roles and permissions, scheduler setup

Technical documentation: DocType reference, hooks and doc events, whitelisted API methods, XML field mapping table, and channel integration notes

User guide plus a live training session for your finance team covering submission, reading SdI outcomes, and running the rejection correction workflow

UAT on a staging site using your own invoices against your provider's SdI test environment where available, with a written go-live and rollback plan

Post-go-live support window for defect fixes and configuration adjustments within the delivered scope

Handover of the full git repository with commit history, so your team or another partner can maintain and extend the app

Deployment runbook covering bench upgrades, migration behaviour, and what to re-verify after an ERPNext point release

Who this is for

Finance Manager / Responsabile Amministrativo

Owns the close and signs off on compliance. Needs every invoice's SdI state visible in one place, rejections surfaced the day they happen, and an archive that stands up to inspection — not a mailbox full of ricevute and a portal login shared by three people.

Accounts Receivable Clerk

Raises dozens or hundreds of invoices a week. Wants FatturaPA XML generated automatically from the Sales Invoice they already post, a plain-language reason when SdI rejects one, and a correct-and-resend path that does not require an accountant or a developer.

ERPNext System Owner / IT Manager

Runs the bench and answers for uptime and upgrades. Wants a proper Frappe app with its own repo, DocTypes, hooks and tests — installable, versioned and migratable — rather than undocumented server scripts and custom fields that break on the next `bench migrate`.

External Accountant / Commercialista

Advises on regime fiscale, Natura coding, ritenuta and bollo treatment, and reviews what actually left the building. Needs the mapping from ERPNext tax templates to FatturaPA codes to be explicit and auditable, and needs to see the exact XML transmitted for any invoice.

How Italy FatturaPA (SdI) Compares

Criterion	ECOSIRE	Custom Build	Competitor	ERPNext Native
FatturaPA XML generation	Generated from the submitted Sales Invoice and validated against the XSD locally before it reaches SdI	Achievable, but the schema, Natura coding and edge cases are all written from scratch by your team	Usually generates XML, though coverage of ritenuta, bollo and PA-specific fields varies by app	None — ERPNext core has no FatturaPA schema, TipoDocumento or Natura concept
SdI outcome handling	Scheduler ingests RC, NS, MC, DT/AT and PA NE notifications and writes readable causes onto the invoice	Often built for the happy path first; rejection ingestion is the part that gets deferred	Commonly covers delivery and rejection; deadline and PA acceptance notices are less consistently handled	Not applicable — there is no transmission, so there is nothing to receive back
Rejection correction workflow	Correct, regenerate under a fresh progressivo, resend, with the whole chain on one timeline	Typically manual — someone fixes the record and re-runs a script, with no linked history	Usually a status flag and a resend button; the audit chain between attempts is often thin	Handled outside ERPNext entirely, in the intermediary's portal
Fit to your tax setup	Explicit mapping DocType over your existing Item Tax Templates, agreed in writing during scoping	Fits exactly, because you specify it — at the cost of your own analysis time	Assumes a reference configuration; unusual regimes often need forked code	Italian Chart of Accounts and tax templates only, with no bridge to e-invoicing codes
Architecture and maintainability	Proper Frappe app — own module, DocTypes, hooks.py doc events, whitelisted APIs and roles	Frequently lands as server scripts and custom fields that break on the next bench migrate	Generally a real app, but built to the vendor's roadmap rather than yours	Any coverage you add is unmanaged customization on core DocTypes
Archiving and audit trail	XML sent and every ricevuta stored as immutable File records with version history and comments	Depends entirely on whether archiving was in the original brief	Records are typically retained; retrieval and defensibility depend on the implementation	No e-invoice artefacts exist to archive
Delivery model and timeline	Build-to-order — two to four weeks from confirmed scope, staging UAT and rollback plan included	Months of internal effort, competing with everything else on the dev backlog	Install in a day, then spend weeks discovering which of your cases it does not cover	Available immediately, and immediately insufficient for Italian compliance
Ownership and lock-in	Full git repository handed over, so your team or another partner can maintain it	You own it outright, along with all future maintenance	Licensed and closed, tied to the vendor's release and support cadence	No vendor dependency, because there is no capability

Frequently Asked Questions about Italy FatturaPA (SdI)

How long does delivery take, and can I download it today?

No — this is build-to-order, not an existing marketplace download. We build it for your environment after you request a quotation. The sequence is a scoping call, a confirmed written scope, then build. Typical delivery is two to four weeks from confirmed scope, depending on how many invoice types (B2B, B2C, PA, self-billing, reverse charge) are in scope and which transmission channel you use. If your scope is larger or your channel is unusual, we tell you the honest timeline before you commit, not after.

Do you transmit to SdI directly, or do I still need an intermediary?

You keep your own accredited channel. The app is built to deliver through the route you already hold a contract for — a certified intermediary's REST API, an SFTP drop, or PEC — and to ingest the ricevute that come back on that same channel. ECOSIRE is a software vendor, not an accredited intermediary, and we do not pretend otherwise. If you have not chosen a provider yet, we scope against a common one and keep the channel layer isolated so swapping it later is a configuration change, not a rewrite.

What happens when SdI rejects an invoice with a NotificaScarto?

The rejection is parsed and written onto the transmission with the SdI error code translated into a readable cause, and the source Sales Invoice is flagged so it does not quietly sit as 'sent'. Finance corrects the underlying data, the app regenerates a fresh XML under a new progressivo di invio, and resends. The original submission, the rejection reason, the correction and the eventual delivery receipt all stay on one timeline, so an auditor can follow what happened without asking anyone to remember.

Which Frappe and ERPNext versions do you support, and what about upgrades?

We build and test against Frappe/ERPNext v15 and v16, targeting the exact version running on your bench. It is a standard Frappe app, so it moves with your bench and `bench migrate` like any other. We include a deployment runbook covering what to re-verify after an ERPNext point release. Version uplifts beyond the delivered scope — for example carrying you from v15 to v16 later — are quoted separately as a small change.

What support and updates are included after go-live?

A post-go-live support window is included for defect fixes and configuration adjustments within the delivered scope. Changes to the FatturaPA specification, new invoice types, or additional transmission channels are handled as scoped change requests and quoted plainly — we do not bundle vague 'lifetime updates' into the sale. You also receive the full git repository, so you are never dependent on us to keep the app running.

Will it work with our existing tax setup, or do we have to redo the Chart of Accounts?

It builds on what you already have. Natura and TipoDocumento codes are resolved through an explicit mapping DocType that points at your existing Item Tax Templates and Tax Categories, so your posting behaviour and Chart of Accounts stay as they are. During scoping we walk your real tax templates and agree the mapping in writing — this is usually where the interesting cases live (esenti, non imponibile, reverse charge, ritenuta), and it is far cheaper to settle it on a call than during UAT.

Can we see it working on our own data before go-live?

Yes, that is the point of the UAT step. We install on a staging site, run your own invoices through generation and XSD validation, and transmit against your provider's SdI test environment where they offer one. You sign off on outcomes you can see before anything touches production, and we go live with a written rollback plan.