Reason Code Reference
Every DocumentQ exception carries exactly one of the codes below. This is the complete set — it is a closed list, and adding to it is a deliberate, documented product change, not something that happens quietly.
Blocking means the document cannot be registered until it is resolved or deliberately overridden by someone with the rights to do so. A few are marked non-overridable, because overriding them would defeat the check.
Where to resolve each one is covered in resolving an exception.
Quantity, price and line checks
| Code | What happened | Severity | Typical resolution |
|---|---|---|---|
ERR-QTY-OVER | The invoice claims more than remains uninvoiced on the posted receipt. | Blocking | Re-count the receipt, or ask the vendor for a credit. |
ERR-PRICE-VAR | Unit price is above the purchase order beyond your tolerance. | Blocking | Approve the increase, or dispute it with the vendor. |
ERR-LINE-MUT | Line amounts disagree with the purchase order even though the invoice total balances. | Blocking | Re-allocate the lines. This one protects inventory valuation, which a total-only check would miss. |
ERR-UOM-MISMATCH | Unit of measure differs and no conversion exists. | Blocking | Add a unit-of-measure conversion, or correct the purchase order. |
ERR-UNKNOWN-ITM | A vendor part number maps to no Business Central item. | Blocking | Create a native Item Reference for that vendor part number, or re-pair the line in the Workspace. |
ERR-TAX-MIS | Tax variance beyond the rounding band. | Blocking | Check the tax group on the item or vendor. |
ERR-CURRENCY | The invoice currency is not the purchase order currency. Currencies are never converted. | Blocking | Usually the wrong purchase order, or a vendor error. |
ERR-UNAUTH-CHG | A charge line (freight, handling, surcharge) is outside the authorized set or over its cap. | Blocking | Confirm the charge was authorized, or reject it. Shown in its own colour, because an authorization gap is not a matching failure. |
ERR-MULTI-PO-PART | A purchase order named on a claim line could not be resolved to an open order for this vendor. | Blocking | Identify the missing purchase order. Read the note below — the name of this code is misleading. |
About ERR-MULTI-PO-PART
The name reads as “an invoice partially spanning several purchase orders”. That is not what it means.
It is raised in exactly one place, for exactly one condition: a claim line named a purchase order number, and that number could not be resolved to an open purchase order for this vendor. Consolidated invoices spanning several orders need no special handling and raise nothing — each line resolves to its own order and reconciles normally.
Diagnosing this code as a “multi-order problem” sends you looking in the wrong place. The five realistic causes, in the order worth checking:
- The order belongs to a different vendor. Open the order and compare its buy-from vendor against the document’s bound vendor. Usually this is a vendor-identification problem, not an order problem — use Confirm Vendor, which re-runs reconciliation.
- The order is no longer open. The lookup is Document Type = Order only.
- The extracted number is not an order number. Vendors routinely print a requisition, contract or quote number in the “PO” field. Open the PDF in the Workspace source pane and read what they actually printed.
- A transcription difference — leading zeros, a prefix, a hyphen. The lookup is an exact key match; there is deliberately no fuzzy matching on order numbers.
- Genuinely several orders, one of which is wrong. The finding is written at header level, so it does not name which one. Read the claim lines’ Associated PO No. column.
If a line names no order at all and your tenant has Open PO Discovery switched off, you will see ERR-NO-AUTHORITY instead — a different code with a different route.
Vendor identification
| Code | What happened | Severity | Typical resolution |
|---|---|---|---|
ERR-VENDOR-UNKNOWN | No vendor candidate cleared the minimum confidence floor. | Blocking | Bind the vendor yourself. The identifying key is remembered for next time. |
ERR-VENDOR-CONTRADICT | Identifying signals point at different vendors — the tax number says one, the bank account another. | Blocking, non-overridable | Disambiguate manually. DocumentQ deliberately never resolves a contradiction by picking the higher score. |
ERR-VENDOR-AMBIGUOUS | Two candidates are within the confidence margin of each other. | Blocking | Choose the right one; the choice is remembered. |
ERR-VENDOR-SELFMATCH | The “vendor” resolves to your own company — your own registration, an intercompany partner, or an excluded profile. | Blocking, non-overridable | Exclude that vendor from identification, or correct the claim. |
ERR-VENDOR-BLOCKED | The vendor is blocked in Business Central. | Blocking, non-overridable | Unblock the vendor in Business Central, or reject the invoice. |
Authority: is there anything authorizing this spend?
| Code | What happened | Severity | Typical resolution |
|---|---|---|---|
ERR-NO-AUTHORITY | No purchase order and no contract stands behind this invoice. | Informational | Code it manually and route it for approval — see invoices with no purchase order. |
ERR-NO-CONTRACT | Non-PO spend with no active authorizing contract. | Blocking | Code it manually, or create the contract. |
ERR-CONTRACT-LIMIT | Over the contract’s cap, or outside its period. | Blocking | Approve the overage, or amend the contract. |
ERR-NO-PREPAY-AUTH | The purchase order does not carry authorized prepayment terms. | Blocking | Authorize the prepayment on the purchase order first. |
ERR-CREDIT-NO-ORIGIN | A credit memo cannot be tied to a posted document. | Blocking | Identify the original invoice. |
ERR-CREDIT-EXCEEDS | The credit is larger than the amount invoiced. | Blocking | Verify with the vendor. |
The document itself
| Code | What happened | Severity | Typical resolution |
|---|---|---|---|
ERR-DUPLICATE | This invoice has already been received, or already posted. | Blocking | Confirm and discard. A byte-identical re-send is superseded automatically instead. |
ERR-CAPTURE-FAILED | Reading the document failed or returned unusable output. | Blocking | Retry capture. If it keeps failing, check the PDF opens and is not password-protected. |
ERR-KIND-UNKNOWN | The document kind could not be determined — invoice, credit memo, statement, something else. | Blocking | Classify it yourself, or discard if it is not an invoice at all. |
ERR-CLAIM-INCONSISTENT | The invoice contradicts itself: its line amounts do not add up to its own stated total. Checked before anything in Business Central is consulted. | Blocking | Use manual coding to enter the real lines. Re-running capture on the same file produces the same reading, so it will not fix a line that was dropped or doubled. |
ERR-NO-CLAIM-TOTAL | No claimed total could be read at all, so there is nothing to check a built invoice against. | Blocking | Re-run capture if extraction never completed; otherwise use manual coding once you have confirmed the real total. |
ERR-CLAIM-INCONSISTENT and ERR-NO-CLAIM-TOTAL are deliberately two codes and not one. The first is a claim whose own line amounts disagree with its own stated net. The second is a claim that states no total at all. Conflating them would show you the same code for two different underlying problems.
When a document has several findings at once
A document can fail more than one check. DocumentQ ranks the open findings, takes the most severe, and shows that one as Latest Error Code. Nothing about this is probabilistic.
| Rank | Code |
|---|---|
| 100 | ERR-VENDOR-BLOCKED |
| 95 | ERR-VENDOR-SELFMATCH |
| 90 | ERR-VENDOR-CONTRADICT |
| 85 | ERR-LINE-MUT |
| 80 | ERR-QTY-OVER |
| 75 | ERR-CURRENCY |
| 70 | ERR-DUPLICATE |
| 55 | ERR-NO-AUTHORITY, ERR-NO-CONTRACT |
| 50 | every other blocking code |
The lower-ranked findings are still recorded as factor rows on the document; they are simply not the headline. This is why ERR-MULTI-PO-PART, at rank 50, is easy to miss on a document that also has a quantity failure.
What decides the outcome
Once the findings are ranked, exactly one action follows:
- No failure at all → the document is Ready.
- A failure whose most severe code is blocked, self-match or contradict → Reject, and the document goes to Exception.
- Any other failure → Review, and the document goes to Exception.
- Then: if the vendor was only proposed and not automatically bound, a Ready result is downgraded to Review. An unconfirmed guess must never reach a posted number.
- Then: if the result is still Ready, the kind is Standard, and both touchless switches are on for this vendor, it is promoted to automatic registration.
There is no step in which a confidence percentage is compared to a threshold, and no path in which anything is posted automatically.