Invoicing with ARCA without leaving your system

In this note · 4 sections

1. Why it gets done separately
2. What building it in means
3. What you can’t skip
4. When it makes sense

At almost every company we work with, invoicing is a separate step. The order is entered in one place, prepared in another, and at the end of the day someone opens the ARCA site or an invoicing program and types the same thing again.

It is duplicated work, but the real cost is not the time: it is that the two records drift apart. The system says one thing, the invoice says another, and when they don’t match nobody knows which one is right.

Why it gets done separately

Because issuing a tax document is not just calling an API. You have to:

• have a digital certificate for each company, managed in ARCA and renewed when it expires;
• request an access token that lasts twelve hours and has to be cached, because if you request it too often they block you;
• follow the sequential numbering for each point of sale and document type, with no gaps;
• know which type of document applies depending on the VAT status of both parties;
• handle the fact that the agency goes down, and that when it does, the sale has already happened.

Each of those points is a different source of errors, and none of them has anything to do with the client’s business. That is why it ends up as a manual step: it’s easier for someone to do it by hand than to build it properly once.

What building it in means

We solved it by building it once, for multiple companies, instead of once per client.

Each company uploads its certificate through a portal and operates under its own CUIT. The system requests the token when needed and caches it until it expires. The gateway keeps the numbering, not a person. And the document type is chosen automatically, by matching the issuer’s VAT status against the recipient’s.

On the client’s side, invoicing stops being a separate screen: it becomes the next state of the order that was already entered.

What you can’t skip

Homologation. ARCA has a test environment that issues documents with fake CAEs. Everything is tested there first, with the homologation certificate, until the numbering and the document types come out right several times in a row. Only then do you touch production.

It sounds obvious, but it is where almost everyone rushes. A document issued wrongly in production can’t be deleted: it is voided with a credit note, which is also a tax document, which also consumes numbering.

The plan for when the agency doesn’t respond. It goes down, and that is not unusual. The system has to be able to record the transaction anyway and retry the issuance later, instead of stopping the sale. A retry queue with backoff handles 99% of cases without anyone noticing.

ARCA’s errors have to be translated. The codes it returns mean nothing to the person at the counter. “Error 10016” has to arrive as “the point of sale is not enabled for this document type,” or whoever reads it can’t do anything about it.

When it makes sense

If you issue only a few documents a day and the volume isn’t growing, a standalone invoicing program is fine. There is nothing to build.

It makes sense to build it in when the data already lives in your system and retyping it is what creates the discrepancy: when the order, the delivery note and the invoice have to be the same thread, or when you run several companies and each one has its own certificate, point of sale and numbering.

In that case the manual step is not just an annoyance. It is where traceability breaks.