Automating tax-compliant invoicing without nasty surprises

In a growing number of countries, invoices aren't documents you print — they're records a tax authority has to authorise before they're valid. Argentina, Chile, Mexico, Brazil, Italy, and progressively the rest of the EU all work this way, with different names for the same mechanism.

For many companies it's still manual: someone logs into the portal, copies the order data, picks the document type, submits it, downloads the PDF and emails it. Multiplied by hundreds of documents a month, that's a hole in the calendar and a steady source of errors that later cost an entire reconciliation.

It can be automated, and it isn't as complicated as it looks. But four things break everyone doing it for the first time, and they're worth knowing before you start.

How it works, briefly

Tax authorities expose web services for issuing electronic documents. The circuit is essentially always the same:

1. Authentication. You obtain an access token signed with the company's digital certificate. It expires and has to be renewed.
2. Query the last number. You ask the authority which document was last authorised for that point of sale and type.
3. Request authorisation. You submit the document data and receive an authorisation code and its expiry.
4. Issue. With the code you build the PDF, store it, and send it.

The technical part is the predictable part. What surprises people is everything else.

The four cases that break

1. Numbering

Documents have to be sequential per point of sale and type. If two processes try to issue simultaneously, or one fails midway, you get a gap — and gaps have to be justified to the authority.

The fix isn't reserving numbers locally: it's always asking the authority which document was last authorised before issuing, and serialising issuance per point of sale. It's slower, and it's the only way to sleep at night.

2. Timeouts that actually succeeded

The classic. The request goes out, the connection drops, no response arrives. Was it issued or not?

If the system blindly retries, it issues twice. If it assumes failure, it leaves a consumed number unrecorded. The only correct path is query before retrying: ask about that document number and see whether it already carries an authorisation code. Any automated invoicing system that skips this check will duplicate documents sooner or later.

3. Customer data

Tax authorities validate. A malformed tax ID, a VAT status that doesn't match the document type, an incomplete address: rejection — and the rejection arrives as a numeric code that explains very little.

Validate before sending, with the same rules, and show the user a message they can act on. And decide what happens to a rejected document: it goes to a visible queue where someone corrects it, never to a log file.

4. The service being down

These services go down, and they tend to go down on the highest-volume days. A serious system queues, retries with increasing backoff, and alerts when the queue grows beyond normal. What must never happen is a sale stopping because the invoice couldn't be issued that instant: record the transaction and let the document go out when the service returns.

What to decide before writing code

• What triggers the invoice? Confirmed order, dispatch, payment? That's a business decision and it shapes the whole architecture.
• Who owns the customer record? If the tax ID lives in three systems with three versions, resolve that first.
• What about credit notes? They usually fall outside the initial scope and show up a week after go-live.
• Where are documents stored? Retention is a legal obligation. PDF and XML, with the authorisation code, have to stay accessible for years.

What you gain

Typical numbers for a company issuing a few hundred documents a month: issuance drops from minutes to seconds, typos in tax IDs and amounts disappear, and the customer receives the document immediately instead of at end of day.

The least-discussed benefit is reconciliation: when the invoice is issued by the same system that records the sale, matching against payments stops being a monthly project.

How long it takes

An e-invoicing integration wired into an existing system is three to six weeks. The technical part is a fraction of that; the rest is agreeing the triggers, cleaning customer data, and deciding what happens to each odd case.

If you're issuing by hand and want to know what it would take in your specific setup, tell us how you invoice today.