Roles, Documents, and Information Flow Across Departments

How information moves across departments (the “handoff” mindset)

Request-to-payment works reliably when each department treats its output as another team’s input. The goal is not only to complete your own task (request, buy, receive, pay), but to pass forward information that is complete, traceable, and referenced consistently. Most downstream errors—wrong invoice coding, duplicate payments, delayed receiving, disputed quantities—come from missing or inconsistent references (e.g., no PO number, wrong line number, unclear receiving document ID).

Think of the cycle as a set of swimlanes (roles) connected by documents (handoffs). Each handoff should answer four questions for the next team: What is being requested/ordered/received/invoiced? How much? Against which reference? Who approved/confirmed it?

Swimlane narrative: main handoffs and documents

Swimlane 1: Requester / End User

• Creates: Requisition (purchase request) with item/service details, needed-by date, delivery location, and suggested supplier (if applicable).
• Hands off to: Approver(s) and Purchasing.
• Key information to pass forward: clear specifications, correct cost center/project, and any constraints (site access, service window, required certifications).

Practical check: If the requester cannot describe acceptance criteria (what “good” looks like), receiving and invoice matching will struggle later.

Swimlane 2: Approver / Budget Owner

• Creates: Approval record (system workflow log or signed approval) tied to the requisition.
• Hands off to: Purchasing (authorization to proceed).
• Key information to pass forward: approval scope (what is approved: amount, supplier, timeframe) and any conditions (e.g., “cap at $10,000,” “use contract supplier”).

Exception ownership: If a later change exceeds approved scope (price increase, quantity increase, new supplier), the approver (or delegated authority) typically owns the decision to re-approve.

Swimlane 3: Purchasing / Procurement

• Creates: RFQ (when competitive sourcing is needed) and collects quotes.
• Creates: Purchase Order (PO) with line items, pricing, delivery terms, and invoicing instructions.
• Receives: PO acknowledgment from supplier (confirmation of acceptance, dates, quantities).
• Hands off to: Supplier (PO), Requester/Receiving (PO details for expected delivery), Accounts Payable (PO reference for matching).

Data quality responsibility: Purchasing is usually accountable for ensuring the PO is matchable: correct supplier, correct ship-to, correct tax treatment, correct unit of measure, and unambiguous line descriptions. A “clean PO” is the single biggest enabler of smooth receiving and invoice processing.

Continue in our app.

• Listen to the audio with the screen off.
• Earn a certificate upon completion.
• Over 5000 courses for you to explore!

Or continue reading below...

Download the app

Swimlane 4: Supplier

• Receives: PO.
• Creates: PO acknowledgment (or confirmation email/portal response), delivery note (packing slip) at shipment/delivery, and invoice.
• Hands off to: Receiving (delivery note with shipment contents) and Accounts Payable (invoice referencing PO and line items).

Reference discipline: Suppliers should be instructed to include the PO number and ideally PO line numbers on delivery notes and invoices. Without these, internal teams must guess, increasing delays and dispute risk.

Swimlane 5: Receiving / Warehouse / Service Receiver

• Receives: goods/services and supplier delivery note.
• Creates: GRN (Goods Receipt Note) or service entry record (confirmation that goods/services were received/accepted).
• Hands off to: Purchasing (for discrepancies) and Accounts Payable (for invoice matching).

Ownership of receipt confirmation: Receiving (or the service receiver) owns the truth of what was actually received and when. This is not a finance activity. Finance relies on the receiving document ID to validate invoices.

Exception ownership: When there is a mismatch (short delivery, damage, wrong item), receiving documents the discrepancy and typically coordinates with Purchasing (supplier resolution) while keeping the requester informed.

Swimlane 6: Accounts Payable (AP) / Finance

• Receives: supplier invoice, PO data, and GRN/service entry data.
• Creates: invoice record in ERP, match results, and remittance (payment advice) after payment execution.
• Hands off to: Supplier (remittance), Purchasing/Requester (queries for exceptions), and Finance (posting, accruals, reporting).

Ownership of payment readiness: AP owns invoice completeness and compliance checks (required references, tax fields, supplier identity, duplicate detection). AP does not “approve” business need; it validates that the invoice is payable against authorized and received items/services.

Data ownership: who creates/updates what (and why it matters)

Vendor (supplier) master data

• Typical owner: Purchasing or a dedicated Vendor Master/Data Governance team; Finance often owns bank details validation.
• Who can request changes: Purchasing, AP, or the supplier (through controlled onboarding).
• Why it matters: Incorrect legal name, tax ID, remit-to address, or bank account can cause payment failure, compliance issues, or fraud exposure.

Item/service and pricing references

• Typical owner: Purchasing (catalog/contract pricing), sometimes Engineering/Operations for technical specs.
• Why it matters: If the PO line description or unit of measure is vague, receiving cannot confirm accurately and AP cannot match invoices reliably.

Receipt confirmation (GRN/service entry)

• Typical owner: Receiving team for goods; service owner/requester for services.
• Why it matters: This is the operational proof that triggers liability recognition and invoice payment eligibility.

Exception approval and resolution

• Price/quantity changes: Purchasing negotiates; approver re-approves if outside authority; AP enforces that approval exists before payment.
• Receiving discrepancies: Receiving documents; Purchasing resolves with supplier; requester confirms acceptability for services.
• Invoice corrections/credits: AP coordinates with supplier; Purchasing supports commercial disputes; receiving supports quantity/condition disputes.

Why accurate references prevent downstream errors

References are the “join keys” that let systems and people connect records without ambiguity. When references are missing or inconsistent, teams resort to manual interpretation, which creates delays and errors.

Critical references to standardize

• PO number: the primary link between authorization (PO) and payment (invoice).
• PO line number: prevents misallocation when a PO has multiple items, partial deliveries, or mixed tax rates.
• Receiving document ID (GRN/service entry number): proves what was received and supports partial receipts and backorders.
• Supplier invoice number: essential for duplicate detection and audit trail.

Common failure patterns (and the fix)

Step-by-step: a “clean handoff” checklist by stage

1) Requisition → Approval

• Requester includes: description, quantity, unit, needed-by date, delivery location, cost object, attachments/specs.
• Approver confirms: budget/authority, business justification, and any constraints.
• System captures: who approved, when, and for what value/scope.

2) Approval → Purchasing (ready to source/order)

• Purchasing verifies: supplier eligibility, correct category, and whether RFQ is required.
• Purchasing ensures: requisition fields map cleanly to PO lines (no “free text” ambiguity where avoidable).

3) RFQ/Quote → PO

• Purchasing converts selected quote into PO lines with: price, currency, Incoterms/ship terms (as applicable), delivery date, and invoicing instructions.
• PO includes: requester contact, ship-to, bill-to, tax treatment, and required references for invoice and delivery note.

4) PO → PO acknowledgment

• Supplier confirms: acceptance, delivery dates, quantities, and any substitutions.
• Purchasing updates: PO delivery schedule or notes; escalates if acknowledgment deviates from PO.

5) Delivery note → GRN/service entry

• Receiving checks: delivery note references PO number and line items; quantities and condition.
• Receiving records: GRN/service entry with PO number, PO line, quantities received, date/time, and delivery note number.
• Discrepancies trigger: notification to Purchasing and requester (for services, acceptance confirmation).

6) Invoice → Match → Remittance

• AP validates invoice: supplier identity, invoice number uniqueness, PO number, PO line references, tax fields, and totals.
• AP matches: invoice lines to PO and GRN/service entry (including partials).
• AP resolves exceptions: routes to Purchasing/Receiving/Approver depending on root cause.
• After payment: AP issues remittance referencing invoice(s) and payment details.

Quick reference: documents, purpose, creator, key fields, downstream users

Mini-scenario: how one missing reference creates a chain reaction

Scenario: A supplier delivers two items under one PO with 5 lines. The delivery note lists only “Office supplies” and no PO line numbers. Receiving books a GRN against the wrong line (same category, different unit price). The supplier invoice references the PO number but not the line numbers. AP matches the invoice to the GRN and flags a price variance on the intended line, while the wrong line appears over-received.

Fix at the source: Require supplier delivery notes and invoices to include PO number + PO line numbers. Receiving should record the GRN by line, using the delivery note line mapping. This prevents mis-posting and eliminates avoidable match exceptions.