Cross-validate
What this page is — the capability that reconciles a transactional document against the order record it belongs to, and re-checks the document's own arithmetic while it is there.
What it is for — so a mistyped price or a swapped bill-to reaches somebody before the invoice is paid, not during the audit.
The problem it solves — a price or address typed wrong on an invoice is found by the customer or the auditor, not by you.
Route: /org/papers/documents/<document>/ai → Comply → Cross-validate ·
Permission: Use AI drafting/extraction/Q&A for documents. ·
Utility: papers_cross_validate · Cost: 450 credits estimated, 1,800 maximum.
1. What it is
It puts an invoice, purchase order or quote side by side with the platform's own order record and flags every discrepancy across five dimensions:
| Compared | Detail |
|---|---|
| Amounts | Subtotal, tax, discount, shipping, grand total |
| Line items | Name, quantity, unit price, line total |
| Currency | Document against order |
| Parties / recipient | Who it is billed to |
| Dates | Document dates against the order's |
And separately, it re-checks the document's own arithmetic. A stated total that does not add up from its own line items is caught even when there is no order to match against — which is why a document with no matching order still returns something useful.
The name "three-way match" appears in the utility's own description, but this version compares the document against the order record only. There is no goods-receipt (delivery) leg, so it cannot confirm what was actually received.
It tells you the invoice agrees with what was ordered. It cannot tell you the goods arrived.
2. Why you would use it
Invoice checking is the archetypal task that is boring, high-volume, and expensive to get wrong. It is also the one people stop doing carefully somewhere around the fortieth document of the month.
high-severity anomalies are a hold-before-pay signal. A grand total exceeding the order, or a changed bill-to party, is exactly the shape of both honest error and invoice fraud.- It catches double-applied tax. The single most common invoice arithmetic error, and one that looks entirely plausible on the page.
checks_passed[]is the part that makes it trustworthy. You see what was verified, not only what failed — so a clean result is evidence rather than an absence of findings.unverifiedis a finding in itself. A transactional document with no matching order in the platform is worth someone's attention regardless of its arithmetic.- It works before the money moves. Recovering an overpayment is an order of magnitude more work than declining to make one.
3. What you provide
| Input | Required | Notes |
|---|---|---|
| Order reference | Optional | The order this document should match — an order number or order ID |
Leave it blank and the tool auto-detects the reference from fields already on the document — PO number, order number, and similar.
Fill it in only when the link is not on the document, or when you want to override a wrong one. That second case is the important one: a document carrying the wrong PO number will confidently reconcile against the wrong order, and every check will pass.
| Example | Meaning |
|---|---|
SO-10429 | Match against this order explicitly |
| (blank) | Auto-detect from the document's PO / order fields |
4. What it reads automatically
| Read | From | Used for |
|---|---|---|
| Document text — the full rendered body | The document | The values being checked |
| Title & family — e.g. "Invoice" / transactional | The document | What kind of reconciliation applies |
| Parties — everyone named | The document | The recipient comparison |
| Key field values — amounts, dates, quantities | The document | The structured side of the comparison |
| Order record | The platform's orders table — or "none found" | The thing being reconciled against |
| Order hints | The document | Order references it detected, when you left the input blank |
This is one of only two capabilities that reads platform data outside Papers — the other being Classify, which reads your type catalog.
5. What you get back
| Field | Type | Values | Means |
|---|---|---|---|
overall_status | enum | match, mismatch, unverified | match = no anomalies; mismatch = at least one; unverified = no order record found, so only internal arithmetic was checked |
anomalies[] | array | — | One per discrepancy |
anomalies[].item | string | — | What was compared |
anomalies[].document_value | string | — | What the document says |
anomalies[].order_value | string | blank when the order lacks it | What the order says |
anomalies[].severity | enum | high, medium, low | high = money or party mismatch · medium = quantity or date · low = cosmetic |
anomalies[].note | string, one sentence | — | What the discrepancy means |
checks_passed[] | string[] | — | Short labels for comparisons that matched exactly |
The severity scale is defined in terms of what differs rather than how much — any money or party
mismatch is high, however small. That is the correct bias for a payment control.
6. Worked example
An accounts-payable clerk opens a supplier invoice before scheduling payment.
Input: order reference left blank — the invoice carries the PO number.
Result — overall_status: mismatch, one anomaly:
Grand total —
highdocument_value: "INR 1,18,000" order_value: "INR 1,08,000" note: "Invoice total exceeds the order by INR 10,000; tax appears applied twice."
What the clerk does with it. high on a money mismatch is a hold. The note supplies the likely
cause — tax applied twice — which turns a query back to the supplier into a specific one: your
system has applied GST at both line and invoice level.
checks_passed[] on the same run listed the currency, the bill-to party, all four line items and
the invoice date. That matters: it tells the clerk the invoice is the right invoice for the right
order and only the tax is wrong, so the correction is a credit note rather than a rejection.
Had overall_status come back unverified, the clerk would have had a different problem — an
invoice with no order behind it at all.
7. Running it
- Open the invoice, purchase order or quote in Orbit Papers.
- Open the AI Assistant drawer, or go to the document's AI workspace.
- Choose Cross-validate under Comply.
- Leave the order reference blank if the document carries one; otherwise type it.
- The result appears in a result tab and is saved to the document.
Treat high-severity anomalies as a hold-before-pay signal, and always open the cited fields
before acting. The result names values; it does not show you the page they sit on.
Available for auto-run from the type's AI Config tab. On on_submit for an invoice type it
becomes a genuine payment control — every invoice reconciled before it reaches anyone's queue. See
AI configuration.
8. The admin contract
| Must be true | Where | What happens if it is not |
|---|---|---|
| Your role holds Use AI drafting/extraction/Q&A for documents. | Role editor | The AI Assistant button does not appear |
The papers_cross_validate utility is active | Orbit AI Flow → utilities | "This utility is currently disabled" |
| The utility is enabled for your organisation | /org/ai-utilities | Absent from Comply, with no error |
papers.ai_monthly_credit_cap not yet reached | System Config | "monthly AI credit cap reached: n of n credits used this month" |
| Orders exist in the platform | Storefront / order records | Every run returns unverified — only arithmetic is checked |
| The document type carries a PO or order-number field | Field schema | Auto-detection has nothing to read, and the reference must be typed every time |
That last row is the difference between a control that runs by itself and one that needs a person to supply the link on every document.
For a confidential document, auto-run is default-denied — a platform administrator must set
papers.ai_confidential_cloud to the literal allow, and the block appears only in the server log.
A manual press still works, and where a local model key is configured the run is forced on-prem and
audited on the timeline as ai_local_routed.
9. Don't confuse this with…
| Cross-document consistency | Finds conflicts between documents in a contract family. This reconciles against an order record |
| Compliance & policy check | Audits clauses against policy. This checks numbers against an order |
| Extract key terms | Pulls values out. This compares them against another system |
| Zonal extraction | Reads values from fixed page positions. This validates whatever was read |
10. Troubleshooting
| Symptom | Cause |
|---|---|
overall_status: unverified | No order record was found. Only the document's internal arithmetic was checked (§5) |
| Every check passed but the invoice is wrong | It may have reconciled against the wrong order — the document's PO number is incorrect. Override it (§3) |
| It cannot confirm the goods arrived | By design. v1 has no goods-receipt leg (§1) |
order_value is blank on an anomaly | The order record does not carry that field — the comparison is one-sided |
A rounding difference is flagged high | Any money mismatch is high regardless of size (§5). Read the note before treating it as serious |
| The order reference was not detected | The document type has no PO or order-number field (§8), or the value is only in the body text |
| The capability is missing from Comply | Role lacks Use AI drafting/extraction/Q&A for documents., or the utility is off for the organisation (§8). The document type does not gate it — AI Config controls auto-run only |