Troubleshooting

The buyer rejects your cXML invoice

An InvoiceDetailRequest is rejected or held, payment slips, and the document itself validates perfectly when you check it.

Short answer

Most invoice rejections are reference failures, not format failures. The invoice has to point at a purchase order line the buyer can find — same order number, same line numbers, same part identifiers, same unit and price basis as the order carried. Where the order and the invoice disagree on any of those, the three-way match fails and the document is held no matter how valid the cXML is.

Causes, most likely first

Ordered by how often each one turns out to be the culprit, not by how interesting it is. Work down the list.

  1. Line numbers do not match the purchase order

    How to confirm: You renumber lines when building the invoice, or you drop a line and close the gap. The buyer matches on their line numbers, not on order of appearance.

    Fix: Echo the buyer’s line numbers from the order exactly, gaps included. Partial invoices reference the original line numbers of the lines being billed.

  2. The unit or price basis differs from the order

    How to confirm: You shipped and billed in a different unit from the one the order specified, or the price basis quantity changed between them. This is the invoice-stage consequence of a unit-of-measure problem that nobody noticed at punchout.

    Fix: Invoice in the unit the order used. If that unit is wrong, correct it on the order through a change rather than silently in the invoice.

  3. The quantity exceeds the tolerance on the order

    How to confirm: An over-delivery, or a rounding difference on a line priced per thousand. Buyers configure a tolerance and reject outside it without negotiation.

    Fix: Invoice what the order permits and raise the excess separately. Ask for their tolerance during setup — it is a percentage they can tell you.

  4. Tax is presented in a form they do not accept

    How to confirm: Tax at line level where they expect it at header level, or the reverse, or a tax jurisdiction element their configuration requires and yours omits.

    Fix: Confirm the tax structure during setup. This varies by country and by buyer, and it is one of the few areas where a general answer is actively unhelpful.

  5. The invoice number has been used before

    How to confirm: A corrected invoice reissued under the original number. Buyers reject duplicate invoice numbers as a financial control and will not override it.

    Fix: Issue a credit note and a new invoice rather than resending a corrected one under the same number.

If it is not on your side

Ask for the specific rejection reason code from their accounts payable system, not the summary the portal displays. The codes map to the causes above directly, and the summary text usually does not.

Check the document itself

Paste your cXML or OCI payload into our free tester. It runs entirely in your browser and reports the structural problems buyers reject on.

Open the tester

Related questions

Why is a structurally valid invoice still held?

Validation and matching are separate gates. The cXML can be perfect and the invoice still fail to match a purchase order line, and only the second one is about money — which is why it is the one that holds payment.

Can we invoice for more than the purchase order?

Only within whatever tolerance the buyer has configured, and that tolerance is theirs to set. Anything beyond it needs a change to the order first, which is a conversation with the buyer rather than a document you can send.

Other failures

Rather not be the one debugging this?

We build and run the endpoint, and deal with the buyer’s technical team directly. Pricing is published in full.

See pricing Send us the error