Platform
One engine. Twelve rules. Every finding explained.
CYOP reads what your ERP already holds, lines the documents up against each other, runs the checks the ERP never runs, and explains every exception in plain English. It advises. Your team decides.
How it works
Read, match, check, explain.
- 01 · Read
From the export you already have
Purchase orders, PO lines, receipts, supplier invoices and invoice lines, from a CSV or Excel export of your ERP. RFQs and BOMs when you have them.
- 02 · Match
Invoice to order to receipt
Invoices to their PO by reference, lines by line number, receipts by order and line. When the reference is missing, R3 suggests the likely PO by supplier and amount.
- 03 · Check
Every active rule, on every record
Twelve deterministic rules across PO and invoice, RFQ and BOM, and workflow. A rule whose fields are not mapped switches off and says why.
- 04 · Explain
A finding a person can act on
Severity, a confidence score with its reasons, the money at stake, a suggested fix and the likely root cause. Then a person decides.
Rules
Twelve rules, and how sure each one is.
Every rule is deterministic: the same records always give the same finding, with the same confidence. The bands below come straight from the rule code.
| Rule | Catches | Confidence | Needs |
|---|---|---|---|
| R1Price above POPO / Invoice | Invoice unit price above the PO price, beyond a 2% tolerance | 90–99%, higher as the variance grows | PO reference, invoice and PO unit prices |
| R2Over-billed quantityPO / Invoice | Quantity billed beyond what was ordered or received (three-way match) | 96% over ordered, 88% over received | PO reference, quantity invoiced, quantity received |
| R3Missing PO referencePO / Invoice | Missing or unknown PO reference, with the likely PO suggested by supplier and amount | Up to 92% when a PO is within 5% of the total; 55% when it needs a person | PO reference |
| R4Duplicate invoicePO / Invoice | Same invoice number, or same supplier, PO and amount within 30 days | 97% same number, 82% same amount | Invoice number |
| R5Payment termsPO / Invoice | Invoice payment terms differ from the PO | 97%: terms are a structured field | PO reference, payment terms on both |
| R6Supplier namePO / Invoice | Supplier name on the invoice differs from the vendor master on the PO | 87–95% for a typo or trading name; 62% for a different legal entity | PO reference, supplier name on both |
| R7Unquoted BOM itemRFQ / BOM | An item on the latest BOM that the RFQ never asked suppliers to quote | 94% | RFQ and BOM |
| R8Quantity driftRFQ / BOM | Same item, different quantity between the latest RFQ and the BOM | 93% | RFQ and BOM |
| R9Spec driftRFQ / BOM | An item quoted to one specification that the BOM now gives another | 85%: a wording-only change can match | RFQ and BOM |
| R10Superseded RFQRFQ / BOM | PO issued against an RFQ revision that has since been superseded | 98% | RFQ and PO |
| R11Retroactive POWorkflow | PO created after the invoice it pays | 99%: dates are structured fields | PO reference, invoice date |
| R12CurrencyPO / Invoice | Invoice currency differs from the PO currency, once an invoice currency field is mapped | 97% | An invoice currency column, added as a custom field |
Anatomy of a finding
Six things on every finding.
Enough to act on without opening another screen, and enough for an auditor to follow the reasoning afterwards.
- 01
A letter on every field it touches
Each exception gets a letter, A, B, C, placed on the order and on the invoice, so the same problem reads the same on both screens.
- 02
The money at stake
Exposure is worked out per rule: the price difference times the quantity billed, the over-billed units at the PO price, or for payment terms the cost of capital on the days that moved.
- 03
A confidence score, with its reasons
Deterministic, from the records: an exact PO reference, matching line numbers, a structured field. The reasons are written out, so anyone can check them.
- 04
The two records, side by side
The fields that disagree, the PO value beside the invoice value. Matching lines stay in, so you can see what was compared.
- 05
A suggested fix
What to do, naming the records: reject, short-pay, link to the suggested PO, raise a change order. CYOP never does it for you.
- 06
The likely root cause
Where the process broke, so it stops recurring: a stale quote, receipts not posted, terms renegotiated by email, a duplicate vendor record.
INV-78122-300 bills 12% above PO price on PO-100300
| Field | PO-100300 | INV-78122-300 |
|---|---|---|
| Line 1 · SRV-2U unit price | 18,900.00 | 21,168.00 |
| Line 2 · PDU-30A unit price | 950.00 | 950.00 |
Why 92%
- Exact PO reference found (PO-100300)
- Largest line variance 12.0% exceeds 2% tolerance
- Vendor and line numbers match, so this is a price issue, not a mis-link
Suggested fix
Reject INV-78122-300 or issue a PO change order on PO-100300 if the price increase was approved. Reference the PO line(s) flagged.
Likely root cause
Vendor price list changed after PO issue, or PO was cut from a stale quote. Check whether procurement re-quoted before cutting the PO.
Severity follows the money at stake for most rules
- Critical
- 100,000 or more
- High
- 25,000 to 99,999
- Medium
- 5,000 to 24,999
- Low
- under 5,000
Checks before posting
Save is held, not refused.
A check puts the draft in a transaction, runs every active rule exactly as a full audit does, keeps the findings that touch the draft, and rolls back. Nothing is saved until someone presses Save anyway, or fixes the field and the mark clears.
What-if checks: change one value, press Check, nothing is saved
| Change | What CYOP says |
|---|---|
| Rename the order number | R3 flags the invoice that now points nowhere, and suggests the renamed order |
| Raise a unit price by more than 2% | R1 flags the price against the PO |
| Lower the received quantity below what is billed | R2 flags the three-way match |
| Change the payment terms | R5 flags the terms against the PO |
| Change the supplier name on the invoice | R6 compares it with the vendor master |
| Move the order date after the invoice date | R11 flags a retroactive PO |
Import and mapping
Your columns, its fields.
Upload a CSV or Excel export. Columns map themselves by name; map the rest by hand. Fields CYOP has no slot for become custom fields, and a rule that uses one switches on. A rule missing a field it needs switches off and says so, instead of flagging every record.
| Rule | Runs when these are mapped |
|---|---|
| R1 | PO reference · invoice unit price · PO unit price |
| R2 | PO reference · quantity invoiced · quantity received |
| R3 | PO reference |
| R4 | Invoice number |
| R5 | PO reference · payment terms on the PO and the invoice |
| R6 | PO reference · supplier name on the PO and the invoice |
| R7–R10 | RFQ and BOM documents, which an order export does not carry |
| R11 | PO reference · invoice date |
| R12 | An invoice currency column, added as a custom field |
Column names CYOP maps on its own
Where the money is
Ranked by exposure, not by date.
Findings sorted by the money at stake and filtered by area, severity and confidence. Vendors ranked by error rate and dollars at risk. First-pass yield measured against the APQC benchmark, month by month. Mark a finding reviewed, or dismiss it.
Dollars at risk by rule
Open findings by severity
| Critical | 29 |
| High | 11 |
| Medium | 9 |
| Low | 4 |
The sample book has errors planted on purpose, about one invoice in seven, so these are not benchmarks.
Available today
What is built, and what is next.
We would rather you knew exactly where the line is. Anything marked planned is not in the product yet.
| Capability | Status |
|---|---|
| Twelve audit rules: PO and invoice, receipts, RFQ and BOM, workflow | Available |
| Severity, confidence with reasons, exposure, fix and root cause on every finding | Available |
| Import from CSV or Excel exports, with column mapping and custom fields | Available |
| Findings ranked by exposure, vendor risk ranking, first-pass yield | Available |
| Checks on a draft before it posts, and what-if checks that save nothingIn CYOP's own invoice and order screens | Available |
| Direct connectors to ERP systemsToday data arrives as an export file | Planned |
| Checks inside your ERP's own save stepNeeds the connector | Planned |
| Scheduled runs on new documents | Planned |
| Pushing approved corrections back into the ERPOnly ever after a person approves | Planned |
See what's sitting in your P2P data.
A 30-minute walkthrough on a sample of your own export. No ERP changes, no procurement cycle.
Read-only. CYOP never writes to your ERP.