Why Hacienda rejects an electronic invoice and how to fix it

Almost no receipt gets rejected because of a software bug. It gets rejected over data: a misplaced CABYS code, a mistyped ID, a repeated consecutive number. Trouble starts when the team treats the rejection as a system failure and reads code instead of reading what Hacienda sent back.

On the projects we have supported, the order that saves the most time is always the same: read Hacienda’s response first, fix second.

Where the invoice gets cut off

A receipt can fail at three points, and each one is fixed differently.

• At intake. Hacienda never receives it: invalid signature, malformed XML or a dropped connection. The document is not registered at all.
• At validation. It arrives but the rules send it back: a CABYS code that does not exist, an ID that does not match the taxpayer registry, totals that do not add up.
• After acceptance. Hacienda accepted it and the customer rejected it from their own system. It happens with large buyers who validate against their own registry. Tech support cannot fix this one; you have to talk to the customer’s purchasing department.

The status and the rejection detail come in the web service response and can be checked in ATV. That is where the useful information is.

The five causes we keep seeing

Wrong CABYS code. A product code applied to a service, or a code Hacienda has since updated. Every line of the receipt is validated against the current catalog.

Duplicate consecutive number. If the connection dropped right after submission, the system retries and issues the same sale twice. Hacienda accepts one and returns the other. The invoice “that never arrived” has usually been accepted already.

Recipient data. A personal cédula has 9 digits, a corporate one 10 and a DIMEX 11 or 12. If the ID type does not match the number entered, Hacienda returns the receipt. The recipient name must also match the registry.

Certificate. The cryptographic key expires. A variation on the same problem: it is installed on the accountant’s laptop and the issuing system never finds it.

New 4.4 fields. Discounts with no code or nature, payment methods the schema no longer accepts in generic form. A correct amount does not save an incomplete XML. Our guide to version 4.4 lists the new fields.

What to look for in the message

Most systems show a red “rejected” label and hide the detail. Ask your vendor whether you can see the exact text Hacienda returned for each document. That message says what to fix and, more importantly, where to fix it.

A simple rule to get your bearings: if the error shows up on every invoice of the day, it is a configuration problem (certificate, consecutive number, a new schema rule). If it shows up on one invoice, it is that sale’s data.

The order that works

1. Check the status in ATV before resending. If it was already accepted, do not issue it again: that creates duplicate revenue and you will need a credit note to undo it.
2. Fix the data where it lives: the product catalog or the customer record. Editing the XML by hand only pushes the problem to the next invoice.
3. Check the consecutive number. After a rejection, some systems leave the range locked.
4. If the certificate expired, request the new key before retrying anything.
5. If the error is structural and affects everything, test in Hacienda’s staging environment.

What happened with the client who resent everything

A restaurant with unstable internet had automatic resending scheduled every three minutes. When the connection came back, the whole batch went out again. Hacienda accepted some invoices and rejected the rest for duplicate consecutive numbers. On Mondays there were forty invoices for twenty sales. It was neither the signature nor Hacienda: it was the retry logic. It was changed to check the status before resending and the problem stopped.

To close

A rejection is diagnosed by reading Hacienda’s response, not by reading code. Most of them are prevented by two things: current catalogs and retries that check the status before issuing.

At DYR Systems the electronic invoicing system stores Hacienda’s full response for every receipt and avoids resending accepted documents. If the rejection keeps coming back after you fix the data, write to us with the message exactly as Hacienda returns it.