Resolving an Exception
Open the document, read the reason code and the decision factors underneath it, then take one of the routes below. The reason code reference lists every code with its typical resolution.
First, read the factors
An exception is never just a code. Underneath it are decision factors: each check that ran, what it expected, what it found, the delta, and the tolerance it was measured against. A quantity failure tells you the receipt showed 5, the claim asked for 8, and the difference is +3.
That is the whole diagnosis, most of the time. There is no confidence score to interpret and no model-written narrative to second-guess.
Route 1 — fix the underlying data
Most exceptions are telling you something true. Post the missing receipt, correct the purchase order, add the item reference or the unit-of-measure conversion, unblock the vendor — then run the document again with Reconcile. It re-checks against the corrected records and produces a real result, not a status flip.
This is the right route for ERR-UNKNOWN-ITM, ERR-UOM-MISMATCH, ERR-VENDOR-BLOCKED, and any quantity failure where the receipt simply had not been posted yet.
Route 2 — bind the vendor
For the ERR-VENDOR-* codes, choose the correct vendor on the document with Confirm Vendor. Nothing is pre-selected — you pick.
DocumentQ then writes that vendor to the document, records the identifying key on the vendor profile so the next invoice from them identifies itself, and re-runs the reconciliation so you see a real reconciliation result rather than just a changed status.
Two of these codes are deliberately not resolvable this way:
ERR-VENDOR-SELFMATCH— the “vendor” resolved to your own company, an intercompany partner, or an excluded profile. Exclude that vendor from identification, or correct the claim.ERR-VENDOR-BLOCKED— the vendor is blocked in Business Central. Unblock them there, or reject the invoice.
ERR-VENDOR-CONTRADICT is also not overridable: the identifying signals point at different vendors — the tax number says one, the bank account another. DocumentQ never resolves a contradiction by picking the higher score. Fix the master data, then reconcile again.
Route 3 — authorize a charge
For ERR-UNAUTH-CHG, confirm the freight, handling or surcharge line was genuinely agreed. This is a deliberate, recorded decision by a person — not a tolerance setting — and it can be configured to force the document into approval.
An authorization gap is not a matching failure, which is why the Workspace shows it in its own colour.
Route 4 — override, deliberately
A user with the rights can override a blocking exception with a recorded reason. The override is written to the audit trail with the code it overrode, and can be configured to force the document into approval. Non-overridable codes stay blocked.
The Workspace’s primary button reads “Accept the vendor’s figure”. It does not do that.
Accept and Override behave identically: both move the document to Ready, and neither carries the vendor’s numbers into the invoice. Register still builds the document from the posted receipt and the purchase order.
On an over-claim this is not a cosmetic difference. After “accepting”, Register builds the correct, smaller invoice — and then refuses it, because the built total no longer matches the claimed total. The refusal is correct behaviour. The button that led there promised something the product deliberately will not do. Expect this if you demonstrate an over-claim.
Which surface resolves which exception
| The exception is… | Resolve it on | By doing |
|---|---|---|
ERR-VENDOR-UNKNOWN, -AMBIGUOUS, -CONTRADICT, or a vendor only proposed | Card or Workspace | Confirm Vendor |
ERR-QTY-OVER, ERR-PRICE-VAR, ERR-LINE-MUT, ERR-UOM-MISMATCH, ERR-UNKNOWN-ITM, ERR-TAX-MIS, ERR-UNAUTH-CHG | Workspace only | Re-pair a claim line to a different order line in the grid, then Reconcile again; or Accept / Override with a note |
ERR-NO-AUTHORITY, ERR-NO-CONTRACT | Card (the Workspace shows a banner pointing you there) | Code and Submit for Approval — see invoices with no purchase order |
ERR-DUPLICATE (possible revision), ERR-CREDIT-*, ERR-CONTRACT-LIMIT, ERR-NO-PREPAY-AUTH | Workspace | Accept / Override / Reject document |
ERR-VENDOR-BLOCKED, ERR-VENDOR-SELFMATCH | — | Not overridable. Fix it in Business Central, then Reconcile again |
ERR-KIND-UNKNOWN, or ERR-NO-CLAIM-TOTAL on an empty claim | Card | Capture — see the narrow rule below |
When a document may be captured again
Capture is normally available only at Received and Capture Failed. There is one narrow exception: a document sitting at Exception may be captured again only when its document kind is still Unknown and both claimed totals are still zero — that is, only a document whose full extraction pass never ran.
A document that completed extraction and then failed reconciliation on the merits is refused, in words. Re-running the model on it would silently discard a real, explained finding.
For the same reason, re-running capture will not fix ERR-CLAIM-INCONSISTENT on a document that did extract: the same file produces the same reading. Use manual coding to enter the real lines instead.
If a document is rejected in approval
If a document is rejected during approval, the resulting Business Central purchase invoice returns to Open but stays unpostable.
The first time you see this it can look like something is broken. It is the guarantee working. A rejected document becoming freely postable again would be the actual problem.