Intake-to-Pay Operating Model Guide

Executive summary

An intake-to-pay operating model describes how a business need becomes an authorized, executed, received, invoiced, and reconciled procurement record. It connects people and decisions across Request, Source, Approve, Award, Execute, Receive, Invoice, and Reconcile. It does not require one application to become authoritative for every data element.

The model is strongest when procurement orchestration retains the work context - the request, evidence, supplier interactions, approvals, exceptions, and status - while the ERP remains authoritative for agreed financial records and postings. The design task is to make every handoff explicit: what moves, who owns it, what evidence travels with it, which system is authoritative, and how a rejected or failed record returns for action.

Table of contents

1. Define intake-to-pay
2. Design the operating record
3. Request
4. Source
5. Approve
6. Award
7. Execute
8. Receive
9. Invoice
10. Reconcile
11. Design ERP handoffs
12. Govern ownership, evidence, and exceptions

1. Define intake-to-pay

Use intake-to-pay when the starting point is a business request and the ending point is a reconciled status suitable for financial completion. It overlaps with related terms:

• Intake-to-procure emphasizes request capture, routing, procurement action, and authorization.
• Procure-to-pay emphasizes requisition, purchase order, receipt, invoice, and payment-related processing.
• Source-to-pay begins earlier with sourcing and may include contract and supplier activity.
• Intake-to-pay connects the entry point to the downstream execution and reconciliation thread.

The labels are less important than the scope statement. Define the start, end, required branches, and system responsibilities for the workflow being designed.

2. Design the operating record

The operating record is the connected context that lets each role understand the same procurement matter without reconstructing it from messages and attachments.

Minimum record components

• request purpose, value, timing, category, location, and requester;
• current owner and status;
• policy route and decision rights;
• suppliers considered and interactions where relevant;
• supporting evidence and version;
• approvals, returns, rejections, and decision notes;
• award rationale where sourcing occurs;
• purchase-order and delivery status;
• receipt or service-entry evidence;
• invoice match and exception status;
• ERP object identifiers and synchronization state;
• open exceptions and next action;
• complete event and decision history.

The record should not duplicate authoritative master data without a synchronization and ownership rule.

3. Request

Purpose: capture enough context to determine the correct route without forcing the requester to understand the entire procurement policy.

Inputs: business need, requested outcome, timing, estimated value, category, location, budget context, known supplier if any, and supporting documents.

Primary owner: business requester until submission; procurement operations after accepted intake.

Control questions:

• Is the request complete enough to route?
• Is the need already covered by a catalog, contract, or approved supplier?
• Does it require sourcing, supplier onboarding, security review, legal review, or an exception?
• Is urgency genuine and documented?
• Is sensitive information being handled appropriately?

Evidence: submitted request, completeness result, routing reason, policy reference, and any return-for-information history.

Output: an accepted request with a route, owner, and next required action.

Useful measures: first-time completeness, clarification rate, time to accepted intake, and route mix.

Northstar Industrial Systems example: Ethan Brooks submits a plant-maintenance service request. The record identifies a required outage window, service location, safety evidence, and budget owner. Maya Chen receives the routed request with the missing-evidence check already visible.

4. Source

Purpose: identify and evaluate supply options when the request requires competition or commercial analysis.

Inputs: approved scope, specifications, supplier pool, evaluation criteria, timetable, confidentiality needs, and commercial rules.

Primary owner: strategic sourcing.

Control questions:

• Are requirements comparable across suppliers?
• Are participants qualified for the event?
• Are evaluation criteria and weights approved before responses are opened?
• Are clarifications shared consistently where required?
• Is negotiation authority defined?

Evidence: event setup, invited suppliers, responses, clarifications, evaluations, negotiation record, conflicts, and recommended scenario.

Output: a supported recommendation ready for approval or award.

Useful measures: sourcing coverage, event cycle time, supplier participation, evaluation completion, and decision reversals caused by missing evidence.

5. Approve

Purpose: obtain the accountable decisions required by policy, value, risk, category, or system design.

Inputs: request context, sourcing recommendation where applicable, budget context, supplier and risk evidence, contract position, and exception history.

Primary owner: the configured approver for each decision; procurement coordinates but does not replace the accountable approver.

Control questions:

• Is the assigned approver authorized?
• Is the required evidence complete and current?
• Are duties separated where needed?
• Can the approver approve, return, reject, request evidence, or escalate?
• Is delegation controlled and visible?

Evidence: decision, timestamp, rationale or note where required, evidence version, delegation, and subsequent change.

Output: an approved, returned, rejected, or escalated record with a clear next action.

Useful measures: approval cycle time, aging by queue, return rate, delegation use, and approvals completed within the configured workflow.

6. Award

Purpose: convert an evaluated sourcing recommendation into an authorized supplier decision.

Inputs: approved scenario, final commercial and technical evaluation, due-diligence status, contract requirements, and exceptions.

Primary owner: strategic sourcing or the accountable award authority.

Control questions:

• Does the selected supplier meet the minimum qualification and due-diligence gates?
• Is the award rationale consistent with the approved criteria?
• Are split awards, alternates, or conditions documented?
• Are unsuccessful-supplier communications controlled?
• Does contract or purchase-order preparation have the correct basis?

Evidence: award decision, rationale, evaluation record, approvals, conditions, and supplier communications.

Output: an authorized supplier and commercial basis for contracting or purchase execution.

Useful measures: award cycle time, conditional awards, award changes, and evidence completeness.

7. Execute

Purpose: turn authorized demand into a purchase action and communicate it to the supplier and ERP according to system ownership.

Inputs: approved request or award, supplier master status, accounting and organizational data, contract references, delivery terms, and ERP mapping.

Primary owner: procurement operations with ERP and integration support.

Control questions:

• Is the supplier record approved and synchronized?
• Are cost center, company, budget, tax, and delivery data valid?
• Which system creates the purchase-order number?
• How are acknowledgements, changes, and cancellations controlled?
• What happens when the ERP rejects the record?

Evidence: purchase-order request, accepted or rejected handoff, ERP identifier, supplier acknowledgement, amendments, and retry history.

Output: an accepted purchase order or an owned exception.

Useful measures: approved-to-order time, first-pass handoff acceptance, acknowledgement status, change frequency, and rejected-record aging.

8. Receive

Purpose: record whether goods or services were delivered as expected and produce evidence for downstream matching.

Inputs: purchase order, delivery or service commitment, shipment or service details, and inspection requirements.

Primary owner: receiving or the business service owner.

Control questions:

• Was the correct item or service delivered?
• Was quantity, date, location, or milestone satisfied?
• Who is authorized to record receipt or service entry?
• Are partial, damaged, rejected, or late deliveries visible?
• Does the receipt synchronize to the ERP?

Evidence: goods receipt, service-entry record, date, quantity, condition, exception, and related documents.

Output: accepted receipt evidence or a delivery exception.

Useful measures: on-time receipt, complete receipt, receipt lag, partial receipt, and unresolved delivery exceptions.

9. Invoice

Purpose: capture the supplier invoice, compare it with the required purchasing and receipt evidence, and route exceptions to accountable owners.

Inputs: invoice, purchase order, receipt or service entry, contract or tax data where relevant, and supplier master.

Primary owner: accounts payable for invoice processing; procurement, requester, receiver, or supplier may own specific exceptions.

Control questions:

• Is the invoice valid and not a duplicate?
• Is a two-way or three-way comparison required?
• Are quantity, price, tax, freight, retention, or service differences within policy?
• Who owns each exception type?
• Is payment readiness distinguished from payment execution?

Evidence: captured invoice, match result, duplicate signal where applicable, exception, resolution, approval, and ERP handoff.

Output: payment-ready status or an owned unresolved exception.

Useful measures: first-pass match, exception mix, exception resolution time, duplicate detection review, and payment-ready cycle time.

10. Reconcile

Purpose: align the procurement operating record with the agreed ERP state and close or carry forward outstanding exceptions.

Inputs: purchase order, receipt, invoice, adjustment, payment or status information, and integration events.

Primary owner: finance operations with procurement and integration support.

Control questions:

• Are procurement and ERP identifiers connected?
• Are rejected, changed, or cancelled states consistent?
• Are unmatched quantities, invoices, credits, or closures owned?
• Which status closes the procurement record?
• What evidence remains accessible for review?

Evidence: reconciliation status, accepted updates, failed or rejected records, corrections, closure reason, and audit history.

Output: reconciled and closed record, or a visible exception with an owner.

Useful measures: open-reconciliation aging, unresolved value, sync failure aging, correction volume, and closure completeness.

11. Design ERP handoffs

Treat every handoff as a contract between systems.

Object contract

For each object, define:

• object and business purpose;
• source system and destination;
• authoritative fields;
• create, update, and cancel direction;
• trigger and cadence;
• identifiers and matching logic;
• required and optional fields;
• validation;
• rejection reason;
• retry rule;
• duplicate/idempotency behavior;
• monitoring and notification;
• reconciliation;
• support owner.

VendrNova has confirmed reusable bidirectional integration frameworks for SAP ECC, SAP S/4HANA, Oracle ERP, Microsoft Dynamics 365, Microsoft Dynamics NAV / Navision, and NetSuite. Every implementation still requires customer-specific objects, mappings, configuration, policies, workflows, and validation. Scheduled synchronization is the normal operating pattern, approximately every two hours, while selected objects may use real-time synchronization based on customer requirements.

The external ERP documentation cited in this guide demonstrates that enterprise systems expose different object-specific real-time, API, and batch patterns. It does not define a universal VendrNova implementation.

12. Govern ownership, evidence, and exceptions

Operating governance

Use three cadences:

• Daily operational review: stuck work, failed handoffs, urgent exceptions, and owner assignment.
• Monthly performance review: volume, flow, exceptions, data quality, adoption, and root causes.
• Quarterly design review: policy changes, roles, integration changes, KPI relevance, supplier and category changes, and controlled improvement.

Exception taxonomy

Classify exceptions by origin:

• incomplete request;
• policy or approval;
• supplier or due diligence;
• sourcing or award;
• master data;
• contract;
• purchase order;
• receipt or service entry;
• invoice or match;
• integration or mapping;
• access or identity;
• data quality.

Every exception needs a severity, owner, target action, evidence, and close reason. Do not allow an "other" category to become the largest category without review.

Minimum acceptance checklist

• [ ] Each stage has a purpose, entry, owner, decision, evidence, and exit.
• [ ] Required branches and skipped stages are explicit.
• [ ] System-of-record responsibilities are defined by object.
• [ ] Failed and rejected handoffs return to a named owner.
• [ ] The ordinary path and major exception paths are tested.
• [ ] KPI definitions use the same stage boundaries as the process.
• [ ] Sensitive evidence handling is approved.
• [ ] The operating model has daily, monthly, and quarterly governance.

Workbook elements

The workbook should include a lifecycle canvas, stage definition sheets, RACI/decision rights, evidence inventory, object handoff register, exception taxonomy, KPI dictionary, and operating-cadence agenda. Northstar Industrial Systems example rows must be labeled fictional.