Italian invoicing is a clearance regime, not a print job. Every B2B, B2C and B2G sales invoice must be transmitted as a structured FatturaPA XML file to the Sistema di Interscambio (SdI), which validates it, forwards it to the recipient and returns a delivery outcome — an invoice only counts as legally issued once SdI accepts it. ERPNext core produces a beautiful PDF and correct tax ledgers, but it has no native concept of the FatturaPA schema, the SdI transmission channel, the TipoDocumento/Natura/RegimeFiscale code sets, the progressive transmission number, or the ricevuta di consegna and scarto (rejection) messages that must be reconciled back onto the invoice. Teams running ERPNext in Italy are left stitching this together with a third-party intermediary and manual re-keying, which breaks the moment volumes rise or a rejection needs correcting.

We build a dedicated Frappe app — a proper installable app with its own module, DocTypes and hooks.py — that closes that gap inside ERPNext instead of beside it. The core is a FatturaPA builder that maps a submitted Sales Invoice to a schema-valid XML: header identity (CedentePrestatore/CessionarioCommittente), line items with the correct VAT nature codes, withholding and stamp duty, payment terms (DatiPagamento), and the mandatory progressive filename numbering. Transmission runs through a configurable channel to your chosen accredited SdI intermediary (via their REST/SOAP endpoint or SFTP), and a set of DocTypes — an E-Invoice log and outcome records — track each message's lifecycle so an accountant can see at a glance which invoices are Sent, Delivered, Rejected or Not Delivered.

Technically it hangs off the events your finance team already uses. A Sales Invoice on_submit doc event (registered in hooks.py, implemented as server-side Python rather than fragile UI automation) validates the Italian field set and enqueues XML generation via a background job so submission is never blocked by a slow gateway. A scheduler event polls the intermediary for SdI outcome messages, parses the returned ricevuta, and writes the result back onto the invoice — flipping a custom status field and, on scarto, surfacing the SItalian error code and message so the invoice can be corrected and re-sent. Cross-border purchases and sales that fall outside SdI are captured for Esterometro/cross-border reporting. Digital signature support (.p7m CAdES) is wired in where your intermediary requires it. Everything is exposed through whitelisted methods and the standard Frappe REST API, guarded by dedicated role profiles and permission rules so only authorised finance users can transmit or reprocess, and client scripts add the reprocess/re-send buttons directly onto the Sales Invoice form.

Because this is build-to-order, we scope it to your actual setup — your intermediary, your company's tax profile, your item and tax templates — rather than shipping a generic binary. After a short scoping call we confirm the field mapping and the SdI channel, build against a copy of your data, and validate end-to-end on a staging bench before touch your production site. Typical delivery is one working week from confirmed scope. You receive the full app source in a git repo, install and configuration on your v15/v16 bench, technical and user documentation, a training session, and a post-go-live support window — so your team owns a maintainable ERPNext app, not a black box.