Building with InvoiceTronic: Italian E-Invoicing Without the Pain

If you've ever tried to integrate directly with the Italian electronic invoicing system — the SDI, Sistema di Interscambio — you know what I'm talking about. It's a government-mandated XML format with its own versioning spec, digital signature requirements, a submission pipeline that involves certificate management, and a delivery status model that can take hours or days to resolve.

I didn't want any of that. I wanted to send invoices.

So I built my accounting system — a full gestionale for Honeyside, my sole proprietorship — on top of InvoiceTronic, a REST API that sits between you and the SDI and handles everything you don't want to deal with. This is what I learned.

What the SDI actually requires

Italian electronic invoicing has been mandatory since 2019. Every invoice between businesses, and most B2C invoices above certain thresholds, must be transmitted through the SDI in FatturaPA format — an XML schema maintained by AgID (the Italian digital agency) that is now on version 1.2.1.

The XML itself is manageable. I built the generator myself using xmlbuilder2 — it's a well-documented format and the spec is public. What's not manageable as a solo developer:

• Digital signature — invoices sent to the SDI must be signed with a qualified certificate (P7M format). Getting and managing that certificate is a process.
• Transmission protocol — you don't POST directly to the SDI. There's an intermediary layer, credentials, and a channel to manage.
• Status polling — after sending, the SDI responds asynchronously. Your invoice might be "delivered", "rejected" (scartata), or stuck in limbo for hours. You need to handle all of that.
• Receiving passive invoices — your suppliers' invoices also arrive through the SDI. Parsing and storing them is a separate problem.

None of this is impossible. It's just a lot of plumbing that has nothing to do with running a business.

What InvoiceTronic takes off your plate

InvoiceTronic is, in practical terms, an SDI intermediary exposed as a clean REST API. You send it XML, it validates, signs, and transmits. You get back a status. When something changes — delivery, rejection, a supplier invoice arriving — it sends you a webhook.

The key things it handles:

XML validation before submission. The SDI returns cryptic rejection codes; InvoiceTronic gives you detailed, human-readable errors at the 422 level before anything reaches the government. For development this alone saved hours.

Digital signing. You don't need a certificate. InvoiceTronic signs on your behalf. For private-sector invoices (B2B/B2C) this is optional but recommended; for public administration it's mandatory. Either way, it's handled.

SDI transmission and status tracking. You fire and forget — the API returns an invoicetronicId and from that point you can poll or wait for webhooks.

Passive invoice reception. Invoices from your suppliers arrive at InvoiceTronic's endpoint, get forwarded to your system via webhook, and you parse them from the XML they deliver. One integration, both directions.

The developer experience

The API is straightforward. Authentication is an API key in the Authorization: Bearer header. The base URL is https://api.invoicetronic.com/v1. There's a sandbox environment, free to use, that lets you test the full pipeline including fake SDI responses.

Sending an invoice looks roughly like:

const response = await fetch(`${INVOICETRONIC_URL}/invoice/send`, {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({ xml: base64EncodedXml }),
});

Status updates come via webhook. The events I handle in production:

• invoice.send.updated — a sent invoice changed state (delivered, rejected, etc.)
• invoice.update.created — an SDI notification arrived for a sent invoice
• invoice.receive.created — a passive invoice from a supplier has arrived

The webhook payload contains enough data to update local state without a follow-up API call in most cases. When it doesn't — when you need the full XML of a received invoice — there's an endpoint for that too.

What I ran into

It's not perfect. A few things worth knowing if you're building on it:

Passive invoice XML isn't always immediately available. When a supplier invoice arrives, the webhook fires quickly — but the full XML sometimes takes a few minutes to be retrievable from the API. I handle this by saving whatever metadata arrives with the webhook immediately, then fetching the full XML on demand (with a retry button in the UI for the rare case where it still isn't available).

The sandbox behaves slightly differently from production. SDI response times, rejection codes, and delivery flows are simulated in sandbox mode. Close enough for development, but don't assume sandbox behavior maps 1:1 to production.

Webhook subscriptions need to be managed. InvoiceTronic doesn't auto-subscribe you to events — you create webhook subscriptions via the API. I manage these through a dedicated section in my gestionale and keep the subscription list in sync on startup.

None of these are blockers. They're the normal texture of integrating with any third-party API. The SDI-related complexity that InvoiceTronic abstracts away is far larger.

The tradeoff

InvoiceTronic is a paid service. There's a cost per invoice transmitted and received. For Honeyside, where invoice volume is low, the cost is negligible compared to the alternative — which would be maintaining my own SDI intermediary setup, complete with qualified certificates and direct protocol integration.

That math doesn't hold for high-volume operations. If you're processing thousands of invoices a month, the economics shift and a direct integration might make sense. For a small studio or a sole proprietorship, it's an easy call.

Would I use it again

Yes. Without hesitation.

The gestionale I built covers the full cycle of simplified bookkeeping for a sole proprietorship: electronic invoicing in both directions, VAT registers, periodic VAT settlements, LIPE reports, F24 generation, a chart of accounts, double-entry bookkeeping, and an asset register. It took a few weeks of evenings and weekends.

InvoiceTronic is the reason the invoicing layer took days, not months. The XML generation, the state machine, the webhook handling — that's all mine. Everything that involves talking to the Italian government is theirs.

That's exactly the division of labor I wanted.