Number7 research · Controller / AP manager / technical buyer
Invoice Extraction Confidence Is Not Transaction Confidence
DIRECT ANSWER Invoice extraction confidence estimates whether a system read a field or structure correctly. Transaction confidence asks whether the underlying payable is sufficiently identified, evidenced, accounted for, controlled, authorized, and executable for the next action. A high-confidence invoice total can coexist with an ambiguous vendor, missing receipt, duplicate obligation, or unauthorized approval.
ORIGINAL NUMBER7 MODELPublished 7 September 2026Vishal Rajput · Founder, Number7 AI
Separate reading from permission to act
Correctly read. Still held.
Illustrative model · not a measured customer result
Document interpretation
0.99 Fields appear reliable
Vendor identity
0.61 Two plausible master records
Accounting proposal
0.88 Relevant prior context
Approval route
Not evaluated
Action heldResolve the vendor, then establish authority.
These illustrative signals cannot be averaged into permission to post.
Field confidence applies to a prediction; transaction readiness applies to an action.
A single averaged confidence score can hide a failed hard control.
Use a confidence vector plus explicit blockers before experimenting with an aggregate score.
Calibrate each signal against its real outcome and cost of error.
Thresholds should depend on the proposed action and materiality, not one universal percentage.
Worked example
An illustrative system extracts an invoice with high field confidence:
Layer
Signal
State
Document/fields
0.99
Invoice number, dates, lines, and totals appear reliable
Identity
0.61
Two vendor-master candidates remain plausible
Evidence
Pass for non-PO flow
Required source invoice present
Accounting
0.88
GL proposal has relevant prior context
Authority
Not evaluated
Approver route has not been established
Execution
Not applicable yet
No target action attempted
A naïve average of the available numeric signals is 0.83. That number is operationally meaningless. Identity is unresolved and authority is unevaluated. The correct state is not “83% ready”; it is “blocked on vendor identity and approval route.”
The smallest human decision is to choose or create the correct vendor record. After that, the system can evaluate the next control.
Counterexample: the confident duplicate
Two invoices from the same supplier show different document numbers but describe the same economic obligation after a resubmission. Every character can be extracted correctly. Field-level accuracy is perfect. Only evidence, identity, and duplicate/economic-event reasoning reveal the risk.
This is why “invoice accuracy” must specify whether it means transcription, field correctness, accounting correctness, or completed transaction outcome.
What an extraction confidence score means
An invoice extraction system commonly returns a value for a field and a confidence or certainty signal. The field may be vendor name, invoice number, date, subtotal, tax, total, or a line item. Microsoft’s invoice model documentation, for example, describes structured fields returned from invoices; platform implementations may expose confidence at different levels. Source: Microsoft Learn: invoice data extraction.
The useful question is not whether the UI shows “98%.” It is whether that score is calibrated for the field, document population, and error definition. Among predictions labeled 0.98, are roughly 98% correct under the chosen ground truth? A score may instead be a ranking signal that is useful for prioritization but not a literal probability.
Even a well-calibrated field score answers only an interpretation question: what does the source appear to say?
Formal distinction
Extraction confidence: a field-, region-, line-, or document-level signal about the correctness of machine interpretation relative to a labeled source.
Transaction confidence: a decision-specific assessment of whether the current economic-event state has sufficient identity, evidence, accounting treatment, control satisfaction, authority, and execution reliability for the proposed next action.
The phrase “decision-specific” matters. The evidence needed to save a draft is not the evidence needed to post a bill, and the evidence needed to post is not necessarily the evidence needed to execute a payment.
Use a confidence vector, not a magic average
Number7 proposes a transaction-confidence vector:
C = [Cᴅ, Cɪ, Cᴇ, Cᴀ, Cʀ, Cₓ]
Component
What it assesses
Example blocker
Cᴅ — Document
Classification, boundaries, fields, lineage
Missing page or uncertain invoice number
Cɪ — Identity
Vendor/entity/master resolution
Two active suppliers share similar names
Cᴇ — Evidence
Required support and consistency
Receipt missing or quantity conflict
Cᴀ — Accounting
Ledger, entity, tax, dimensions, period
Tax treatment unresolved
Cʀ — Rights/Authority
Policy and permitted actor/state transition
Approval threshold not satisfied
Cₓ — Execution
Idempotency, target acceptance, and verification
API timeout with unknown target state
Do not average these components by default. If authority is absent, strong document and identity signals do not make the transaction authorized. If execution state is unknown after a timeout, retry risk cannot be erased by a correct total.
A safer decision rule is:
Permit an action only when all mandatory controls pass and each action-relevant confidence component meets its calibrated threshold; otherwise create a named exception.
Thresholds depend on action and error cost
The same proposal can be acceptable for one action and unacceptable for another:
Proposed action
Possible threshold posture
Pre-fill a review form
Lower threshold; human sees source and proposal
Auto-assign a low-risk coding suggestion
Calibrated threshold with visible correction path
Post a bill
Higher thresholds plus identity, evidence, accounting, and authority controls
Trigger money movement
Separate, stricter authorization and execution controls; outside AIdaptIQ’s current product claim
Threshold design should incorporate false-accept cost, false-reject cost, materiality, reversibility, and downstream detection. One global “95% confidence” rule is not a control design.
Evidence behind the next action
Keep the source with the assertion.
Source
Original document and exact page or region
Interpretation
Machine proposal or human-confirmed decision
Control
Rule and pass, fail or unevaluated result
Outcome
Authorized action and verified target state
After a QBO create request times out, the outcome is unknown. Verify whether the target bill exists before a bounded retry; a timeout is not evidence that nothing was created.
Separate critical fields and high-cost actions from low-risk metadata.
Measure precision and error rate inside score bands, not only overall accuracy.
Plot reliability: predicted confidence band versus observed correctness.
Test by vendor, document family, scan quality, language, client/entity, and time.
Record abstentions and human corrections.
Sample high-confidence auto-accepted items for silent errors.
Recalibrate after material model, prompt, parsing, or population changes.
For transaction components such as authority, “pass/fail/not evaluated” may be more honest than a probability.
Go deeper where you need to
Technical appendix: Evidence travels with the accounting assertion.
Retained evidence fields
01
Source
Retain the original source document and version. A later corrected document should be linked to the earlier source rather than silently replacing it.
02
Locator
Point to the exact page, region, line or source field supporting the value. A reviewer should be able to reach the evidence from the accounting assertion.
03
Assertion lineage
Distinguish what the source says, what the model proposed and what a person confirmed. Retain the producer and state version behind each material assertion.
04
Control result
Record the evaluated rule, inputs and pass/fail/unknown result. A confidence score does not replace evidence that a mandatory control was satisfied.
05
Supersession
Retain the earlier assertion and the reason a new one became active. A later reviewer should be able to reconstruct the value used for the authorized action.
Validation questions for this model
Freeze the population and workflow boundary.
Define required evidence and successful exit state.
Measure exceptions, human touches and silent errors.
Separate modeled outcomes from production measurements.
Technical appendix: State → controls → resolution → authorized action.
Why a generic agent loop is not enough
A common AI-agent pattern is plan, call tools, observe, and continue until the task appears complete. That is useful for many knowledge-work problems. Finance operations add requirements that the generic loop does not guarantee: economic-event identity, accounting treatment, policy, segregation of duties, materiality, action authority, duplicate-safe execution, and evidence retained for later review.
The architecture should therefore center the transaction, not the agent conversation. The system may use models and agents inside stages, but they should read and update governed state through explicit transitions.
The operating model
1. State
State is the current, versioned representation of the economic event and its evidence. It includes source lineage, proposed fields, entity candidates, supporting documents, accounting proposal, exception status, approvals, and target-system history.
State must distinguish:
observed source facts;
model/system proposals;
human-confirmed decisions;
control results;
authorized actions;
verified external outcomes.
Without those distinctions, later reviewers cannot tell what was known, inferred, decided, or executed.
2. Controls
Controls evaluate whether a proposed state transition is permitted. Examples include:
required fields and source lineage;
arithmetic consistency;
vendor/entity identity;
duplicate/economic-event checks;
PO/receipt/contract evidence;
coding and tax requirements;
value thresholds and approval routes;
segregation of duties;
connector and target-system constraints;
idempotency and retry policy.
A control returns a named result: pass, fail, not applicable, not evaluated, or insufficient evidence. A vague “confidence looks good” is not a control result.
3. Resolution
When a mandatory control does not pass, the system creates a typed exception. Resolution supplies the missing fact, decision, authorization, or evidence needed for the next evaluation.
The system should pre-assemble a decision packet and ask the smallest question possible. The person should not need to rediscover the entire transaction.
4. Action
An executor performs only the action allowed by the current state and authority. The action should carry a stable transaction ID, idempotency key where supported, actor/authority context, target object, and expected outcome.
Actions may include saving a draft, requesting evidence, sending an approval, creating a bill, or recording a payment state. These actions have different risk and authority requirements.
5. Verification
Verification proves what changed. It records the target response and, when needed, reads the target state back. A 200 response or outbound email log may not establish the business outcome.
Verification can close the transaction, create a new exception, or safely trigger a bounded retry.
The transition record
Every material transition should record:
Field
Purpose
Transaction and state version
Connects the event across time
Evidence references
Shows what the transition relied on
Proposal and producer
Separates model/system suggestion from source fact
Control and result
Explains why the action was or was not allowed
Resolution/actor
Records human or system decision and authority
Action and idempotency key
Makes execution traceable and duplicate-safe
Target response/object ID
Links to the downstream system
Verification result
Proves the actual outcome
Timestamp and environment
Supports chronology and debugging
This is not a claim that every event needs the same storage or retention. It is the logical evidence required for controlled operation.
Worked example: QBO bill posting after an API timeout
State: invoice is extracted, vendor resolved, coding reviewed, and external approval received.
Controls: required evidence, arithmetic, duplicate candidates, and authority pass for the supported workflow.
Action: executor sends a bill-creation request with a stable local transaction ID.
Observation: the request times out. The local state is “target outcome unknown,” not “failed.”
Resolution/control: retry policy requires checking the target system for a corresponding object before another create.
Verification: target lookup finds the bill and stores its ID. Transaction moves to verified posted state.
If the system had treated timeout as absence and retried blindly, it could have created a duplicate. The verifier is not an optional logging step; it changes the safe next action.
Counterexample: human approval over an incomplete state
A reviewer receives an email containing only a PDF and “approve?” They click approve. The workflow now has a human-in-the-loop, but the person may not have seen duplicate candidates, receipt mismatch, coding, or approval limit.
Human presence did not create control. The decision packet, authority, and state completeness determine whether the approval is meaningful.
Control before autonomy
Autonomy should increase along two independent axes:
proposal autonomy: how much the system can interpret, assemble, and recommend;
action autonomy: which state transitions it can execute without a person.
A system can have high proposal autonomy and deliberately limited action autonomy. That is often the right early design for finance: let AI do the evidence-heavy preparation while controls and authority govern irreversible or material actions.
How to implement the model
Define the transaction unit and state schema.
Separate source facts, proposals, decisions, and outcomes.
Name each permitted state transition.
Attach explicit controls and authority to each transition.
Type failure and uncertainty using the AP exception taxonomy.
Design the smallest-decision packet for each recurring exception.
Make external actions idempotent where possible.
Verify the target state and handle unknown outcomes explicitly.
Log events needed for touch, STP, error, and audit analysis.
Version policies, models, prompts, connectors, and state changes.
Limitations
The model does not prescribe a specific database, orchestration framework, accounting policy, or legal control environment. Not every workflow requires a human resolution. Conversely, a typed state does not make an unsafe policy safe. Organizations must design controls with qualified finance, security, risk, and systems owners.
The phrase “verifier proves” means operational evidence of the defined target outcome, not mathematical proof or assurance engagement.
Sources
Number7 Research operating architecture: State → Controls → Resolution → Action → Verification, revision 1.0.
Citing this companion model
Number7 Research. “Controlled AI in Finance: State, Controls, Resolution, Action.” Number7AI, revision 1.0, 7 September 2026. https://number7ai.com/research/transaction-confidence/#guide-state-controls-resolution-action.
Original model provenance
Revision
Date
Change
Reviewer
1.0
7 September 2026
Initial state/control/resolution/action/verification model and example
Number7 AI editorial review
Apply this companion model
Choose one external action and document its permitted states, controls, authority, idempotency behavior, and verification proof.
Method, sources and limitations
Limitations
The confidence-vector model does not prescribe universal components, weights, or thresholds. Some states are categorical controls rather than predictions. Components may be dependent: an identity error can alter the accounting and duplicate assessment. Calibration requires representative labeled data and can drift.
Do not publish one aggregate transaction-confidence score until its semantics, calibration, control gates, and failure costs are documented. A vector is less marketable but more truthful.
BY NUMBER7 AI