# Invoicing with ARCA without leaving your system

> Electronic invoicing is usually a separate step that someone does by hand at the end of the day. What it takes to build it into the system your team already works in.

Field note No. 01 · Tax · August 26, 2026 · 3 min read
By: Juan Pedro Gachet, co-founder and director at Mithandir · https://mithandir.com/en/blog/facturar-en-arca-sin-salir-de-tu-sistema

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.

---

More field notes: https://mithandir.com/en/blog · Talk to the team: https://mithandir.com/en#contacto