P2P · Non-PO invoice exception

Non-PO Invoice Journey

Shows how a Non-PO invoice moves through tax, bank, commodity, coding, approval, and posting loops as agents assemble context, recommend resolution, route delegation of authority, and trigger a governed FB60 posting after human approval — with evidence, replay, and learning.

Open P2P mission Open replay

Demo spine

Signal → context → agent → policy → evidence → decision → action → replay

Signal

Non-PO invoice

A supplier invoice with no purchase order enters the P2P exception queue.

Context

Invoice + vendor 360

Agents read vendor master, tax registration, bank details, commodity, prior coding, and approval history.

Policy

No-PO/No-Pay + DofA

Coding, tax, bank-verification, materiality, and delegation-of-authority rules are evaluated.

Agent

Non-PO fleet

Coding, tax, bank-validation, duplicate, and approval-routing agents recommend a resolution with confidence.

Decision

Approve + post

Analyst approves the recommended coding and routing; a governed FB60 posting is triggered through the gateway.

Assurance

Evidence sealed

Coding basis, policy result, evidence pack, and posting reference are available to supervisor and auditor.

Evidence contract

What stakeholders can inspect

Fact	Source	Proof
Invoice header	Ariba/SAP context cache	Vendor, amount, currency, tax code, commodity, document date.
Vendor + bank	Vendor master	Tax registration, validated bank account, payment terms, risk flags.
Coding basis	Coding history	Prior GL/cost-center coding, sampled confidence from accepted history.
Governed posting	SOR gateway	FB60 posting prepared behind the policy gate (dry-run by default), with CHG and ledger entry.

Outcome

What changes

Analyst effortCoding + chasing avoided

Cycle timeException loops collapsed

Control stateHuman approval before posting

LearningCoding confidence updated

Evidence Replay Value

Assurance proof

Policy, human gate, learning, value, and SOR access

Control	Visible proof
Policy evaluated	No-PO/No-Pay, coding tolerance, tax validation, bank verification, duplicate check, and delegation-of-authority threshold.
Human gate	Analyst approval required before FB60 posting; supervisor escalation for materiality or DofA breach.
Learning captured	Accepted/rejected coding, tax, and bank recommendations feed the Non-PO coding-confidence model.
Value attribution	Effort avoided, cycle-time reduction, duplicate-payment risk, and discount capture are attributed at case, vendor, tower, and CFO levels.
SOR access	Invoice and vendor facts read from context cache; SAP FB60 write only after policy gate. Avoided-SAP-call count is not claimed unless gateway telemetry records it.