e-Invoicing in practice: why the tax authority rejects an invoice — and how to avoid it

We connected our invoicing system to e-Faktura, the e-invoicing system of the Public Revenue Office (UJP). The documentation changed while we worked, and we learned things that are not in any guide.

This is useful whether you use our software or someone else's. The basics — what e-invoicing is and who it applies to — are in a separate article. This one is about practice.

1. The most common error: data does not match the registry

The tax authority checks every invoice against its registry. If the buyer's name or address is not letter for letter identical, the invoice is rejected with error E1000.

Letter for letter means literally. Two spellings of the same company form are the same company to a person — but not to the system, and the invoice fails.

What to do: take each client's details once, exactly from the registry, and store them that way. Not from old invoices, memory or a business card.

2. An invoice has eight states, not two

It is easy to think an invoice is either "sent" or "not sent". The system knows eight states — among them rejected, corrected and recorded.

In practice: sending it does not mean it was accepted. If your software only shows "sent", you do not know whether it was rejected. Always check the actual state with the authority.

3. Sixteen tax indicators

When an item is VAT-exempt or has special treatment, it is marked with a tax indicator. There are sixteen, each tied to a specific article of the law.

A wrong indicator means either a rejected invoice or — worse — an accepted invoice with the wrong VAT. Do not guess: ask your accountant which indicator applies to each special case.

4. The server clock must be accurate

Every invoice carries a creation time, and it must be within five minutes of the authority's server time.

If the clock on the server you send from drifts, invoices are rejected — and the error looks mysterious, because everything else is correct. Check this first when there is no other explanation.

5. Invoices are signed with the company's e-signature

Every invoice is digitally signed with your company's certificate. The certificate file and its password are the key to all your invoices.

Keep them separately. If the file and the password sit in the same place and that place leaks, the certificate has to be reissued — which is exactly what we had to do.

6. Test first, then production

The authority provides a test environment. Before going live, try every document type you use — a regular invoice, an advance invoice, a credit note and a debit note. Each has its own rules.

7. The documentation changes — follow the latest

The official guide exists in several versions. Comparing the PDF guides with the live web specification, we found things the PDFs did not have. Software built only from an old PDF can have errors that stay hidden until invoices start being rejected.

Five questions for your software provider

• Are client details taken from the registry, or typed by hand?
• Do you show the actual state from the authority, or just "sent"?
• Do you support all 16 tax indicators?
• How is the certificate stored, and is it kept separate from the password?
• Which version of the specification is it built on?

If the answers are vague, ask before you start — not when invoices start being rejected.