DIR3: three codes without which the invoice is rejected
It is the silliest piece of data and the one that sends back the most invoices. It cannot be deduced, it cannot be invented and nobody in your office knows it: the body you are invoicing has to give it to you.
The codes from the Directorio Común de Unidades Orgánicas y Oficinas that identify the three administrative units an invoice addressed to a public authority passes through.
When you invoice a public authority, your invoice does not reach «the town council»: it reaches three different units, and each one has its code in the common directory.
- Accounting office. Whoever registers the invoice and books it.
- Managing body. The department the expense is charged to.
- Processing unit. Whoever commissioned the work and has to sign it off.
All three travel inside the Facturae file. If one is missing, the entry point returns the invoice without any person having seen it.
Where they come from
From the body itself. They usually come in the contract specification, in the order or on the authority's website, and they can also be looked up in the common directory. What you cannot do is guess them: they are not derived from the NIF or from the name.
They are asked for once per client and stored on their record. They only change when the authority reorganises, which happens, but not often.
An example of what it costs
You invoice on the 2nd, you assume it is registered, and the rejection arrives on the 5th to an inbox nobody looks at. By the time someone sees it, it is the 20th. The public sector contracts act's 30-day deadline had not started running: it starts on the day of a valid registration. That is eighteen days of payment lost over three codes.
The mistake that comes up most
Copying the codes from another invoice to the same body. Inside a large authority dozens of processing units live side by side, and the one for Culture is not the one for Public Works. The file validates, goes in and sits stuck at the wrong unit, which is worse than a rejection: nobody returns it and nobody pays it.
Where this carries on in Cairos: Invoicing with the data each client requires.
Terms that go with this one
Almost no tax concept makes sense on its own. These three are the ones that most often turn up beside it.
Facturae
The XML format used to issue invoices addressed to a Spanish public authority, signed electronically and submitted at an entry point such as FACe.
Payments and bankingDue date
The date on which the amount of an invoice becomes payable and from which it starts to generate interest for late payment.
InvoicingSequential numbering
The obligation to number invoices consecutively within each series, with no gaps and no repeats.
This, handled without thinking about it
Cairos keeps the invoices, the record books and Hacienda's forms from the same data, so the theory on this page turns into boxes that are already filled in.
No card and no minimum term.