Ten invoice fields that cause most rejections

When a first batch of e-invoices fails, the cause is rarely exotic. It clusters in the same small set of fields, and almost every one of them is a record that was never maintained because nothing had ever checked it.

The authoritative list of validation rules is the PINT OM specification, and your service provider will give you the exact rule behind any failure. What follows is where to look first.

1. The buyer's tax identifier

Missing, out of date, belonging to a different group entity, or stored in a notes field rather than its own. This is the single most common failure, and it is a customer master data job, not an IT job.

2. Your own identifiers

Your TIN, your VAT registration and your commercial registration have to be consistent with what the Oman Tax Authority holds. A mismatch here fails every invoice rather than some of them.

3. The invoice type code

A tax invoice, a simplified invoice, a credit note and a debit note are different documents with different codes. Systems that treat a credit note as an invoice with negative numbers fail here.

4. Tax category at line level

Standard-rated, zero-rated and exempt lines have to be distinguished on the line, with the right category code and rate. Applying one treatment to a whole invoice is the habit that breaks.

5. Tax arithmetic

Line tax has to be consistent with its taxable base and rate, and the tax breakdown has to reconcile to the totals. Rounding applied at the wrong level is the usual culprit — a rounding policy that was invisible on a printed invoice becomes a validation failure.

6. Currency

The invoice currency has to be a valid code, and an invoice in a foreign currency carries extra obligations around the tax amount. Hard-coded assumptions about OMR are a common source of failure for exporters.

7. Dates

Issue date, supply date and due date are separate fields with rules about their relationship. Defaulting all three to today passes on most invoices and fails on the interesting ones.

8. Units of measure

Quantities need a unit from a standard code list. "Each", "unit", "pcs" and an empty field are all the same thing to a person reading an invoice and all different to a validator.

9. References

A credit note has to reference the invoice it corrects. Purchase order and contract references, where your customer requires them, have to be in their own fields rather than in a description line.

10. Addresses and country codes

Addresses that were written for a printed page — the whole thing in one free-text block — fail a structure that wants the country as a code and the parts of the address in separate fields.

Nine of these ten are fixed in your customer and item master, by someone who understands the business, before any software is involved.

How to find your own problems early

1. Export a month of invoices and count how many have a buyer tax identifier. The percentage is usually a surprise.
2. List your distinct units of measure. If there are forty, there are not forty.
3. Find last year's credit notes and check each one references an invoice.
4. Take ten invoices to your prospective service provider and ask them to validate the data as it stands.

That last one is the most useful hour you will spend, and it is a reasonable thing to ask for before signing anything — see the questions to ask before you sign.

For what the specification is actually checking, see PINT OM in plain language.