EyeTrustAIFor invoice-automation providers
Less manual invoice checking.Controlled error risk.
Control extraction error risk in your product, within the limits you set.
Conformal prediction & risk control1,000 invoices · In scope, with other controls cleared
- 350 capture checks
- 65 audits
- 585 checks avoided
Prepared outcomes, not measured customer results. Error tolerance applies to original extractions eligible to skip checking, before audit.
Your extractor. Your product.
Matching, approval and payment controls stay in place.
The full workflow
From reviewed invoices to less checking.
- 01 / Define
Choose the errors that matter.
Specify the invoice fields, document scope and error tolerance for your workflow.
- 02 / Establish
Build the evidence.
Check original extractions against their invoices. Assess how much checking the evidence supports removing.
- 03 / Operate
Reduce checks. Keep auditing.
Activate the supported policy, retain the required reviews and reassess when conditions change.
Follow every step: setup, warm-up, review, assessment, activation and recovery.
Go directly to the guided walkthroughThe science & the demonstration
Evidence for a defined error risk.
Statistical risk control connects your error tolerance to reviewed examples of your AI’s work. The error definition, invoice population and evidence determine the scope of the guarantee.
This walkthrough uses synthetic invoices and prepared outcomes. It illustrates the workflow; it does not establish invoice-specific performance.
Inspect the invoice evidence & evaluation planSix fields in this example
- Supplier identity
- Invoice number
- PO reference
- Currency
- VAT total
- Gross total
A wrong or missing critical field counts as an invoice error. Original extractions remain preserved when the working record is corrected.
Do fewer checks actually save time?
First identify the task that disappears. If someone must open the same invoice for coding, matching or approval, only the extraction-checking time that is actually removed counts as saved.
Ongoing work
Retained capture checks, random audits, adjudication, monitoring and incident investigation. Compare the time each task takes; a difficult exception and a random audit may take different amounts of time.
Setup & reassessment
Pairing source documents with original extractions, reference labeling, scorer assessment, integration and each new evidence round. Track this effort separately and state the period over which it is recovered.
For this example:
1,000 × minutes per baseline capture check
− non-audit capture checks × minutes per retained check
− audits × minutes per audit
− additional recurring staff time
= net recurring staff minutes saved
Use the counts for the selected policy above. The audit checks are already included in retained total checks; do not subtract them twice. Measure task times and overhead rather than assuming a standard number of seconds per invoice.
Scoring, hosting and integration charges belong in a separate cost comparison. No staffing reduction, monetary saving or payback period is measured in this demo.
Which numbers are real, prepared or still missing?
- 8 interactive practice invoices
- Fictional documents and extractions. Your review choices exercise the workflow; they do not fit a scorer or produce a statistical bound.
- 2,400 pairs / 1,600 grouped situations
- An explicitly loaded, authored warm-up cohort. The alternative insufficient-evidence branch has 280 pairs / 180 groups. Neither is a recommended evidence requirement.
- 1,000-invoice operating example
- Separate prepared counts for workload and errors. These are not independent measured test results or a replay of the practice labels.
- Upper bound & confidence setting
- Authored policy fields, not computed statistics. The three budget profiles are illustrations, not a measured risk–workload curve.
- Not yet established here
- Invoice scorer performance, a validated statistical procedure for this population, a matched baseline comparison, post-audit error rates and measured net time or cost savings.
Adoption
Start with one customer workflow.
Compare error risk and checking effort against the controls already used in that deployment.
A measured comparison
Reviews avoided, remaining errors and total effort—including audits and scoring.
A defined scope
Which invoices the evidence supports, and which still need checking.
An operating plan
Integration, named owners, monitoring and conditions for stopping or resuming.
Proposed evaluation outputs. The walkthrough demonstrates the workflow with synthetic records; invoice-specific performance must be established with your evidence.
Who does what?
EyeTrustAI
Assess the scorer and evidence. Evaluate error risk and checking effort, and define the integration plan.
Your product team
Own integration, extraction versions, product controls and monitoring. Connect the review workflow and implement fallback.
Your customers’ finance teams
Agree critical fields and acceptable risk. Provide qualified reviews and audits; retain matching, approval and payment authority.
Agree these roles, source access and owners for suspension, impact review and recovery. This is a proposed evaluation scope.
Who supplies the score—and what must it prove?
The proposed EyeTrustAI role
Prepare or assess a scorer for your source documents, extracted fields and error definition, then evaluate the risk-control policy. A scorer ranks original extractions by risk; it is not itself an error guarantee, and raw extractor confidence is not automatically a suitable substitute.
In this walkthrough
invoice-fidelity@0.3-demo and its scores are authored fixtures. No fidelity model runs here. The interface does not establish a production-ready invoice scorer or its price.
Before deployment
Test whether the score distinguishes incorrect extractions—including confidently wrong ones—from correct ones. Compare the deployment’s existing controls, the score alone and the calibrated policy on a held-out evaluation. A score that cannot separate cases may offer too little review reduction, even if a conservative policy can control risk.
Scorer choice, hosting, per-invoice cost and throughput belong in the scoped evaluation. A suitable scorer may need adaptation or development; that work and its cost must be agreed.
Can we reuse reviewed invoices or extend the scope?
Reuse evidence when its history is intact
We can assess existing reviewed examples if they retain the source invoice, original extraction and versions, explicit correct/error outcomes and sampling history. Corrected final records alone do not show whether the original was correct; uncorrected records are not automatically clean. Check missing cases, supplier/template dependence and whether the data still represents current work.
Keep evaluation data separate from scorer fitting and policy selection. Reuse is a deliberate assessment, not automatic carry-over. This demo archives prior rounds without counting their labels as new evidence.
Start with the work actually being checked
This example covers six header fields on English, EUR invoices from known suppliers for one entity, up to €25,000. Credit notes, line-item coding and other languages are outside its illustrated scope. Adding German invoices, new entities or layouts requires assessing that population and its evidence; it is not a settings-only extension.
For structured e-invoices, first establish whether extraction checking is needed at all. Benefits depend on the actual manual task, not on calling every document an invoice.
Size the effort from your evidence
Agree the target risk, supplier/template mix, review quality and amount of reusable evidence before estimating new labels or duration. Smaller accounts may not have enough evidence or volume to justify a separate policy; pooling requires a defensible shared population. There is no universal label count or deployment time.
What would integration involve?
Proposed integration · no live invoice API in this demo
Keep your extraction pipeline and accounting integrations. Assess original extractions to establish where capture checks can be reduced.
- PairSource + original extraction + versions
- AssessScorer + policy + declared scope
- RecordReview or capture-handoff receipt
Inputs, outputs and retry behaviour
Input identity
Use stable document and extraction IDs, immutable source and original fields, extractor/schema/scorer versions, entity and scope metadata, and required control flags. Preserve corrected working records separately.
Output contract to agree
A version-bound assessment and decision receipt should identify the source, original extraction, policy, reason and audit selection. Label events should record the reviewer, outcome, source reference and relevant versions. They do not approve, post or pay an invoice.
Retries and reprocessing
Retries of the same request must not create duplicate handoffs or redraw audit selection. Agree idempotency and deduplication across EyeTrustAI and your queue. A changed source or re-extraction creates a new version and assessment; never attach an old receipt to new fields.
Fallback, data location and operating requirements
Retain capture review on timeout, unavailable scoring, missing input, incompatible versions or a suspended policy. Existing business holds remain authoritative. Agree timeouts, retry limits, capacity and outage handling before connecting a production workflow.
Agree where scoring runs and what data moves. Specify permitted source access, hosting, retention/deletion, credentials and logs. This browser-only demonstration neither proves an on-premises deployment nor promises that a production service keeps all data on your system.
Updates need an explicit review. Model, scorer, schema or declared-scope changes require checking evidence compatibility before reuse. The same versions can also encounter different data; audit outcomes and population monitoring remain necessary.
Tell us about your invoice product.
Choose one customer workflow to evaluate.