Facturae: the invoice the authority will actually accept
You do not send a public authority a PDF by email. You send it an XML file, signed, through a specific registry. And if a piece of data is missing, it is the registry that rejects it, not a person.
The XML format used to issue invoices addressed to a Spanish public authority, signed electronically and submitted at an entry point such as FACe.
Ley 25/2013, on promoting electronic invoicing, has required since 15 January 2015 that suppliers to public authorities — sociedades anónimas, sociedades de responsabilidad limitada, temporary business consortia and a few other forms — invoice electronically. Its article 4 also leaves a door open: each authority may exclude invoices of up to €5,000 from the obligation, so it is worth checking what yours has decided before taking anything for granted.
What it is exactly
Facturae is not «a PDF with a signature». It is an XML with a closed schema, today at version 3.2.2, where each piece of data goes in its own tag: the issuer, the recipient, each line with its base and its rate, the breakdown of output tax, the withholdings in their own separate block and the due dates.
Three things make it different from an ordinary invoice:
- It goes electronically signed in XAdES format. Without a signature, the registry will not accept it.
- It is delivered at a general entry point, not by email. The one for central government is FACe, and many regions and town councils have their own.
- It carries the body's three DIR3 codes. Without them it is rejected, and there is no way to work them out: the body itself provides them.
What is checked before it is accepted
The validator is arithmetical and it does not forgive: the sum of the line amounts has to equal the gross total, the sum of the tax due in the breakdown has to equal the total output tax, and the payment instalments have to add up to the amount to be performed. One cent out from rounding and the file comes back.
An example
You invoice a town council €3,200 plus VAT. The usual PDF will not do: you have to generate the XML, sign it with your certificate, go into whichever entry point that council uses and register it. From that moment the 30-day payment deadline in the public sector contracts act starts running, and that is the real reason to get it right first time: a rejection does not delay the invoice, it delays getting paid.
The mistake that comes up most
Assuming that signing the PDF is enough. Electronically signing a PDF does not turn that PDF into a Facturae invoice: the registry expects an XML with a specific schema and discards anything else. It is the most common reason an invoice to a public authority spends three weeks «sent» and is registered nowhere.
Where this carries on in Cairos: Electronic invoicing, explained.
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.
DIR3
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.
InvoicingCorrective invoice
The invoice that corrects one already issued, in its own series and referring expressly to the invoice being corrected.
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.