Reviewing vendor invoices
What this page is — the reviewer's guide to the Vendor inbox: what arrives there, what the automatic checks are telling you, and what each decision does to the invoice, the supplier and your ledger.
What it is for — turning a pile of supplier PDFs into posted bills without typing them, and without paying the same invoice twice.
The problem it solves — an accounts payable team that keys invoices by hand is slow and, worse, has no memory: the duplicate that arrives six weeks later under a slightly different file name looks exactly like new work.
Route: Orbit Books → Purchases → Vendor inbox Permission: Review vendor invoice submissions: process, accept, reject, ask for information. Holders of View vendor bills, payments and AP aging. can read the inbox without acting on it.
Why you would use it
Every invoice in the inbox has already been attributed to a supplier, because it could only be uploaded by a contact you invited on behalf of that supplier. That single fact is what makes the automatic checks possible: the system can compare the document against bills you already hold from the same company, against the tax number on file, and against the limits you set for it.
Your job shrinks to the part a person is actually good at: deciding whether an exception matters.
Before this works — the admin contract
The inbox stays empty unless an administrator has enabled the portal on the entity and invited at least one supplier contact. See Vendor portal setup.
Two more things shape what you see:
- The reading utility. Invoices are read by the Books document-reading utility. It needs to be enabled for your organization and the organization needs AI credits. Without it invoices still arrive, marked plainly as not read, and you type the fields yourself.
- The processing job. In an environment where that job is switched off, uploads sit in received until a reviewer presses Process now on a row.
The Vendor inbox
The inbox opens on everything needing attention, which means the two statuses where a person is the next step.
| Status | Meaning | Your next step |
|---|---|---|
| Received | Uploaded, not read yet | Wait, or press Process now |
| Processing | Being read right now | Wait |
| Needs review | Read, checked, waiting for you | Decide |
| Waiting on vendor | You asked a question | Wait for their reply, which returns it to Needs review |
| Accepted | A bill was created from it | Nothing here; work in Bills |
| Rejected | Closed, with your reason | Nothing; the supplier may upload a corrected invoice |
Open a row to get the original file, the fields that were read from it, the supplier's own typed details, the risk flags, the plain-language explanation where there is one, and the full timeline.
What the reading extracts
| Field | Used for |
|---|---|
| Supplier name and tax number | Checked against the supplier record |
| Invoice number | Duplicate checks against bills and other open uploads |
| Invoice date and due date | Sanity check, and the dates on the bill |
| Currency and grand total | The bill total, the credit-limit check and the duplicate-amount check |
| Line items with amounts | The bill lines, and the check that they add up to the total |
| Confidence | How sure the reading is, which drives the low-confidence flag and auto-accept |
Where the reading and the supplier's typed details disagree, the reading wins on screen and the typed values fill any gaps. You can override any field before accepting, and your edits are what the bill is built from.
Field reference — the risk flags
Thirteen checks run on every invoice. Their severity is fixed, and the invoice's overall level is the worst flag it carries.
| Flag | Severity | What it means |
|---|---|---|
| Same file uploaded before | Blocking | An identical file already exists for this entity |
| Invoice number already billed | Blocking | A bill with that supplier invoice number already exists for this supplier |
| Invoice number already in the queue | Warning | Another open upload from the same supplier carries that number |
| Same amount within a few days | Warning | A bill of the same total from this supplier is dated within five days |
| Tax number does not match | Blocking | The tax number printed on the invoice differs from the one on the supplier record |
| Tax number is not valid | Warning | The tax number read from the document fails its format check |
| Low reading confidence | Warning | The document was read with less than 90 per cent confidence |
| Totals do not add up | Warning | The line amounts differ from the grand total by more than one unit of currency |
| Dates look wrong | Information | The due date is before the invoice date, or more than 180 days after it |
| Amount over the limit | Blocking | The total exceeds the supplier's credit limit, or the entity's extraction limit |
| Purchase order reference missing | Blocking | The entity requires one on every supplier invoice and none was given |
| Bank details change pending | Blocking | The supplier has asked to change its bank details and nobody has decided yet |
| KYC not approved | Blocking | The entity requires KYC and this supplier's required documents are not all approved |
Where the level is warning or blocking, an AI explanation is added: two to four sentences saying what the flags mean together, plus a suggested action of accept, ask for information or reject. It is advice, not a decision, and it can be re-requested from the invoice with Explain risk. If your organization has no AI credits the flags are still there; only the sentences are missing.
Your four decisions
Accept. Creates a draft bill from the extracted fields plus your edits, links the uploaded file to it, closes the upload and e-mails the supplier. If the invoice carries a blocking flag you must type an override note first, and that note is kept on the timeline. Where an active bill-approval workflow exists, the new draft is sent into it immediately.
Ask for information. Needs a note saying what you want. The supplier receives it, can reply with a message and one extra file, and their reply brings the invoice back to Needs review with both attached.
Reject. Needs a note saying why. The supplier is told, and may upload a corrected invoice as a new document. Nothing is created in the ledger.
Mark duplicate. A rejection that also records what it duplicates: an existing bill of the same supplier, or another upload from that supplier. Use it rather than a plain rejection, because the link is what makes the history readable later.
Worked example
An invoice from Alpha Traders arrives for 11,800. The inbox shows two flags: tax number does not match, blocking, and low reading confidence, a warning. The explanation says the tax number on the document differs from the one on file, that the amounts agree, and suggests asking the supplier which registration it invoices from.
The reviewer opens the file, sees a legible invoice from a second branch of the same company, and chooses Ask for information: "Please confirm which GSTIN this branch invoices from — the one we hold is 29ABCDE1234F2Z4."
The supplier replies from the portal, attaching the registration certificate. The invoice returns to Needs review with both on the timeline. The reviewer updates the supplier record, re-runs the checks with Process now, and the blocking flag is gone. Accepting now creates the draft bill; because this organization runs a bill approval workflow, the bill goes to the finance manager rather than straight to draft, and the supplier is told it was accepted.
Bill approval after accepting
Where a workflow exists, the invoice row shows that its bill is waiting for approval. An approval clears the bill in the usual way. A rejection at the approval stage is internal: the bill returns to the reviewer and the supplier is told nothing, because the supplier already had a decision from you and a second contradictory message would only confuse them.
The KYC review queue
Purchases → Vendor KYC lists documents suppliers have uploaded, newest first, with the supplier, the document type, its number and validity dates.
Open one to see the file, then approve or reject it. A rejection needs a note, which the supplier receives. On approval you may set or confirm the date the document is valid until. A newer approved document of the same type replaces the older one, and a supplier who uploads again before you have decided replaces its own earlier upload rather than queueing two.
A supplier's overall status is derived from the required types: approved only when every required type has a current approved document, and otherwise rejected, expired or pending, in that order of seriousness. Where the entity requires KYC, that status is what the blocking flag on invoices reads.
Profile change requests
Suppliers may edit their own address and contact details directly. Tax numbers and bank details are different: those become a request that a person has to decide, from the vendor's record.
Approving applies the change to the supplier record and tells the supplier. Rejecting needs a note and changes nothing. While a bank request is pending, every new invoice from that supplier carries a blocking flag, which is deliberate: it is the exact moment invoice fraud is attempted, and it forces the payment to wait until somebody has confirmed the new account by another channel.
Troubleshooting
| What you see | Why | What to do |
|---|---|---|
| The tab is missing | The role lacks the review permission, or was granted it after sign-in | Grant it and sign in again |
| Rows stay in Received | The processing job is off in this environment | Use Process now, or ask for the job to be enabled |
| "AI reading is not configured; review manually" | The reading utility is not enabled for the organization | Enable it, or type the fields and accept |
| Reading was deferred | The organization ran out of AI credits; the upload retries with a growing delay | Top up credits, or use Process now once they are available |
| Accept is refused | The invoice has a blocking flag and no override note | Resolve the cause, or type an override note explaining the decision |
| Accept fails with a bill error | Something about the extracted data is not valid for a bill, for example a bad date | The upload returns to Needs review with the reason; fix the field and accept again |
| The explanation never appears | The level is only informational, or AI is unavailable | Use Explain risk on demand; the flags are unaffected |
| An accepted invoice shows no bill number | The bill is a draft, and numbers are allocated when it is posted or issued | Work with it in Bills |