The Accounting System I Built for Myself

Every freelancer with a VAT number has a conflicted relationship with accounting software.

Generalist software — the kind everyone uses — is designed for the common case. The freelancer with Italian clients, standard invoices, ordinary VAT, and an accountant who handles the rest. If that's your case, it works.

My case is not that.

I have Italian clients and international clients. I have invoices with ordinary VAT, invoices with reverse charge, invoices outside the VAT scope for digital products sold abroad. I have Stripe purchases that become costs, SaaS subscriptions to capitalize, depreciation to calculate. I need to generate LiPE every quarter, produce XML files for the SDI (Italian electronic invoicing system), and keep VAT registers in a format my accountant can read.

No software I tried handled this flow without requiring workarounds that themselves became a problem to manage.

The Decision to Build It

I didn't build Gestionale Molinari to prove something. I built it because the cost of adapting to software that didn't work for me had exceeded the estimated cost of building something of my own.

It's an evaluation I make rarely — usually the right answer is to use what already exists. But in this case the domain was narrow enough to be manageable, my needs were specific enough not to find a match in existing products, and the complexity was high enough to justify the investment.

The stack is MERN — MongoDB, Express, React + Vite, Node.js. There was no strong technical reason to choose it; it's the stack I know best, and for a project you build mostly alone, familiarity matters more than theoretical optimality.

What It Actually Does

The system starts with invoicing. I can create invoices, associate them with clients, generate the FatturaPA 1.2.1 XML file, and send it to the SDI via InvoiceTronic's APIs. The system handles different VAT regimes — ordinary, reverse charge, outside scope — and produces the correct nature code based on the type of operation.

VAT registers update automatically when I record an invoice. At the end of each quarter, the system calculates the periodic settlement — the VP section of the LiPE — from data already in the registers. It's not a form I fill in manually; it's a calculation that starts from the data and arrives at an XML file ready to send.

There's a basic ledger — fundamental accounting entries — and fixed asset management with depreciation. It's not an ERP; it doesn't handle analytical accounting or produce a full statutory balance sheet. It's exactly what I need to manage a small sole proprietorship on simplified ordinary accounting.

The Sistema Nexus Webhook

One of the most recent features — and the most technically interesting — is the integration with Sistema Nexus, the payment router I built for my master's thesis.

Nexus fires a webhook to the management system every time a transaction completes. The system receives the event, determines the correct VAT regime based on the nature of the transaction and the client's origin, and automatically generates the FatturaPA. For international clients paying via LemonSqueezy, the invoice is outside the VAT scope — LemonSqueezy is the Merchant of Record and assumes fiscal responsibility. For Italian clients paying via Stripe, the invoice has ordinary VAT and is sent to the SDI.

Stripe/LemonSqueezy → Sistema Nexus → Gestionale Molinari → SDI

This cycle — from transaction to electronic invoice — is completely automatic. When a payment arrives, within a few seconds the invoice is generated, sent, and recorded in the ledger.

What I Learned Building It

The Italian tax domain is more complex than it looks from the outside, and more coherent than it seems when you're inside it.

FatturaPA has hundreds of fields, but most are optional or get the same value in ninety-five percent of cases. VAT nature codes follow a precise logic once you understand the underlying model. The LiPE is just a structured communication of data you already have if your accounting is in order.

I understood these things by building the software that implements them. I wouldn't have understood them by reading the Revenue Agency's documentation.

There's value in implementing from scratch the things you use, even when ready-built alternatives exist. Not always — but when the domain is narrow enough and the use case specific enough, building gives you an understanding that using doesn't.

Will I Use This Forever?

Probably not. At some point Barba Studio or another product will grow enough to require an accountant who uses standard tools, and I'll need to migrate.

But for now it works, it's mine, and every time I use a feature I built exactly for my case there's a satisfaction that no off-the-shelf software can give.