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 one working week. 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.