STATUS: EXTERNAL — share-safe, bounded, regulator-visible.
Apply External / Share-Safe Codex AI rules.
Owner review required before publication.
Thesis
“Procure-to-pay automation can create financial consequence unless payment, invoice, supplier, budget, authority, and policy state remain admissible at the moment of commit.”
Flow (conceptual)
Purchase order / invoice / payment proposal → authority and state validation → execution admissibility boundary → allow / block / escalate → payment or obligation execution
What this is
A placement pattern for an execution admissibility boundary inside procure-to-pay (P2P) flows where automation can create:
- a financial obligation,
- a supplier commitment,
- an accounting impact,
- or an actual payment release.
It ensures that P2P execution only proceeds when admissibility resolves at T=0, at the point where the institution becomes bound.
Where consequence binds
Consequence binds at the commit points where the system:
- creates or changes an obligation that downstream processes treat as authoritative, and/or
- releases a payment (or an irreversible payment instruction), and/or
- commits an invoice state that drives financial recognition and settlement.
These are not “workflow steps”; they are the points where institutional consequence becomes real.
Why “approval” is not enough (drift)
In P2P, a prior approval can become invalid without any malicious intent. Common drift conditions include:
- Approval drift
- Approvals can become stale if amounts, items, terms, or risk conditions change.
- Supplier status drift
- Supplier status can change (suspension, sanctions screening, onboarding status, risk rating, banking details).
- Budget state drift
- Budget availability and allocation can change between approval and commit due to other commitments or reforecasting.
- Delegation drift
- Delegations can expire, change scope, or become invalid due to role changes or thresholds being crossed.
- Payment release risk
- The act of release can occur after material state changes (bank account updates, fraud controls triggered, or exception modes in effect).
These are reasons to enforce admissibility at commit, not to add friction earlier. The aim is to ensure that what was approved is still admissible when it binds.
What must be admissible at T=0
At the commit boundary, admissibility must resolve with current:
- Authority
- Who is accountable for this obligation or release right now?
- Under what delegation and threshold is it permitted?
- Invoice / payment state
- Is the invoice/payment proposal still valid in its current form (amount, currency, terms, beneficiaries)?
- Supplier state
- Is the supplier currently admissible (status, risk, banking details integrity, required checks current)?
- Budget and financial state
- Is budget still available and correctly allocated for this commitment?
- Are there conflicting commitments or holds?
- Policy and constraints
- What rules apply right now (separation of duties, limits, prohibited categories, exception handling)?
- Context
- What business purpose and case context does this transaction belong to (project, contract, incident, emergency mode)?
- Evidence
- What evidence supports admissibility, and what must be bound to the commit for later review?
AoR mapping (commit surfaces)
AoR contributes by mapping:
- the commit surfaces in the P2P lifecycle (obligation creation, invoice commitment, payment release),
- the control expectations attached to those surfaces (who must be able to authorise what, under which constraints),
- and the data and state dependencies that must be current at T=0.
The aim is to make “where consequence binds” explicit, so the admissibility boundary can be placed deterministically.
SCIA Runtime enforcement (conceptual)
SCIA Runtime enforces the P2P commit boundary conceptually by:
- resolving admissibility from current enterprise state,
- applying applicable constraints and authority at T=0,
- and requiring evidence to be bound to the commit decision.
This is not post-event audit. It is pre-execution admissibility at the point of financial consequence.
Typed outcomes
The boundary should yield operationally meaningful outcomes such as:
- Allow
- Allow with conditions
- Block
- Escalate
What this is not
- Not Oracle configuration guidance
- Not implementation steps
- Not API specifications or schemas
- Not proprietary decision logic
- Not a policy overlay applied after the event
IP boundary
This page specifies architectural intent and placement only:
- No platform configuration detail
- No schemas
- No code
- No proprietary logic
Request Briefing
Request a briefing to select one P2P workflow, identify its commitment and release surfaces, and define the T=0 admissibility boundary where financial consequence binds.