Agile DataWarehouse

Insights

Procure-to-Pay Reporting: Purchase Orders, Approvals, AP, and BigQuery Model

Procure-to-pay reporting guide for growing companies: purchase requests, POs, approvals, receiving, vendor bills, payments, controls, and BigQuery model.

Procure-to-pay reporting shows how planned spend becomes approved purchases, vendor bills, payments, and cash outflow.

For many growing companies, that process is visible only in pieces.

The department head sees a purchase request. Operations sees a purchase order or fulfillment status. Finance sees a vendor bill after it reaches the accounting system. Leadership sees operating expense, cash, budget variance, or working capital after the spend has already moved.

That may work while the company is small. It becomes fragile when spend volume grows, more people can commit the business to purchases, vendor terms become more complex, and finance needs to forecast cash before invoices arrive.

Procure-to-pay reporting connects the path from request to approval, purchase order, receipt or service completion, vendor bill, payment, and exception handling. It gives CFOs, COOs, founders, finance leaders, operations leaders, and heads of data one practical view of committed spend, actual spend, and cash timing.

The goal is not to build a complicated procurement dashboard.

The goal is to help the business answer a direct question:

What have we committed to spend, what has already become payable, what still needs approval or matching, and what will affect cash?

What procure-to-pay reporting should answer

Procure-to-pay reporting should make spend visible before it surprises finance.

A useful report should answer:

  • which purchase requests have been submitted
  • which requests are approved, rejected, pending, or stale
  • which purchase orders are open, partially received, fully received, canceled, or closed
  • which vendors, departments, projects, products, locations, or owners are involved
  • which spend is committed but not yet billed
  • which goods have been received or services completed
  • which vendor bills have been received
  • which bills match the purchase order and receipt data
  • which bills are blocked, disputed, duplicated, or missing approval
  • which payments are due this week, this month, or later
  • which spend belongs in budget variance, cash forecast, working capital, or board reporting
  • which records do not reconcile
  • who owns each exception

This is broader than a payables report.

Accounts payable reporting is essential once the vendor bill exists. Procure-to-pay reporting starts earlier. It shows the spend pipeline before the invoice reaches AP, then connects that pipeline to bills, payments, and cash timing.

If vendor bills, approvals, and payments are managed in Bill.com, the Bill.com to BigQuery reporting guide covers the AP system layer that should connect to purchase orders, commitments, accounting, cash forecasts, and reconciliation checks.

That earlier visibility matters because leadership often needs to manage spend commitments before they become accounting actuals.

Why procure-to-pay reporting gets hard as companies grow

Procure-to-pay reporting usually breaks because purchasing, operations, and finance systems were not designed together.

Each function may have a reasonable workflow. The reporting problem appears when the company needs one connected view.

Purchase requests and finance actuals are separated

A purchase may start as:

  • an email request
  • a procurement form
  • a spreadsheet row
  • a purchase requisition
  • a project estimate
  • a signed vendor quote
  • a credit card transaction
  • a purchase order
  • an invoice submitted directly to accounting

Finance may not see the spend until a bill or card charge appears.

That delay weakens cash planning and budget control. A department may already believe spend is approved while finance still sees no obligation. Leadership may review budget variance after the commitment is effectively locked in.

Procure-to-pay reporting should label each stage so leaders can separate requested spend, approved spend, committed spend, billed spend, paid spend, and forecast spend.

Approval status lives outside the accounting system

Approval workflows often happen in procurement tools, email, spreadsheets, corporate card platforms, project systems, or messaging threads.

Common approval issues include:

  • missing approver
  • approval outside policy
  • approval after the purchase happened
  • split purchases that avoid approval thresholds
  • stale pending requests
  • emergency purchases without reason codes
  • approvals that do not include department, project, or budget mapping
  • vendor bills that arrive without a matching request or purchase order

If approval status is not represented in reporting, finance can see the bill but not the control history behind it.

That creates friction during close, audit preparation, budget review, and cash planning.

Receiving and service completion are invisible

For product companies, procurement reporting often depends on whether goods were received.

For service businesses, the equivalent question may be whether work was completed, a milestone was accepted, a subscription period started, or a project deliverable was approved.

If receiving or completion status is not connected to purchase orders and vendor bills, the company may struggle to answer:

  • did we receive what we ordered?
  • did the vendor bill before delivery?
  • is the bill amount different from the purchase order?
  • should the cost be accrued?
  • is inventory or project cost recorded in the right period?
  • is an unbilled commitment missing from the cash forecast?

This is where procurement reporting connects to inventory reporting, working capital reporting, and month-end finance controls.

Vendor data is inconsistent

Vendor identity sounds simple until reporting needs to connect multiple systems.

Common issues include:

  • duplicate vendor records
  • vendor name changes
  • parent vendors and local subsidiaries
  • different vendors for ordering, billing, and payment
  • contractor names that do not match payment records
  • card merchant names that differ from accounting vendors
  • vendors mapped inconsistently across departments
  • missing tax, payment term, or contract fields

If vendor identity is inconsistent, spend by vendor, AP aging by vendor, purchase order matching, cash forecast, and contract renewal reporting become harder than they should be.

The reporting model needs a vendor dimension that can handle practical business reality, not just the exact names exported from each source.

Commitments are missing from the cash forecast

Finance can forecast cash more accurately when it sees expected vendor obligations before invoices arrive.

Procure-to-pay reporting should expose:

  • approved purchase requests not yet ordered
  • open purchase orders not yet billed
  • partially received orders
  • recurring vendor commitments
  • planned renewals
  • unpaid vendor bills
  • scheduled payments
  • disputed or blocked payments

Without that view, cash forecasts often depend on memory, emails, or side spreadsheets.

The cash flow reporting guide covers cash movement. Procure-to-pay reporting supplies one of the key forward-looking inputs: what the business has already committed to spend.

How procure-to-pay differs from AP reporting

Accounts payable is a critical part of procure-to-pay, but it is not the whole process.

AP reporting usually focuses on:

  • vendor bills
  • open balances
  • due dates
  • AP aging
  • payment status
  • payment priority
  • vendor concentration
  • disputes and holds
  • reconciliation to the accounting system

Procure-to-pay reporting adds the upstream and control view:

  • purchase requests
  • approval policy
  • purchase orders
  • committed spend
  • receipt or service completion
  • three-way match where relevant
  • budget mapping
  • contract or renewal context
  • exception ownership
  • cash timing before the bill arrives

The two views should connect.

AP should not be isolated from the request, approval, PO, receiving, budget, and operational context that created the obligation.

Core metrics to define first

The strongest procure-to-pay reports start with a small set of defined metrics.

The definitions matter because the same spend can appear at several points in the process.

Requested spend

Requested spend shows what teams have asked to buy.

Define:

  • which request statuses count
  • whether rejected and canceled requests are retained
  • which date controls the period
  • whether the amount is estimated, quoted, approved, or final
  • which department, project, location, or owner receives the spend
  • whether tax, freight, fees, and renewals are included

Requested spend is useful for demand visibility, but it should not be presented as a financial obligation unless the business treats it that way.

Approved spend

Approved spend shows purchases that passed the required control step.

Define:

  • approval thresholds
  • required approvers
  • policy exceptions
  • approval date
  • approval owner
  • whether approval can expire
  • whether approval applies to a one-time purchase, recurring spend, or contract term

This metric helps finance and operations distinguish controlled spend from informal demand.

If budget owners are involved, approved spend should connect to budget variance reporting so leaders can see when future spend is likely to move the budget view.

Committed spend

Committed spend usually means the business has made a purchase commitment, often through a purchase order, signed quote, contract, or vendor agreement.

Define:

  • what creates the commitment
  • whether canceled or closed POs remain in history
  • how partial receipts reduce open commitment
  • how change orders are handled
  • how multi-period contracts are split across periods
  • how currencies are converted
  • which source system is authoritative

Committed spend is one of the most useful procure-to-pay metrics because it bridges operations and finance.

It shows obligations that may not yet appear as accounting actuals.

Received or completed spend

Received or completed spend shows goods received, work completed, or service periods delivered.

Depending on the business, this may come from:

  • inventory receiving
  • warehouse management
  • project management
  • subscription records
  • service delivery systems
  • operations signoff
  • manual receiving logs

This metric supports accruals, bill matching, inventory reporting, and period-end cutoffs.

It also helps finance ask a practical question: should we expect a bill, accrue the cost, challenge the bill, or keep the PO open?

Billed spend

Billed spend shows vendor invoices that have been received.

Define:

  • bill date
  • accounting period
  • due date
  • vendor
  • department
  • expense category
  • project or customer association
  • PO or receipt match status
  • approval status
  • dispute or hold status

This connects directly to accounts payable reporting, where open bills, aging, payment timing, and reconciliation become the main focus.

Paid spend

Paid spend shows what has left or will leave cash.

Define:

  • payment date
  • scheduled payment date
  • bank posting date
  • payment method
  • partial payment logic
  • vendor credit handling
  • payment batch status
  • cash forecast period

Payment timing should be clear because accounting expense timing and cash timing may differ.

That distinction is important in operating expense reporting, where run rate, accrual timing, budget impact, and cash outflow should not be blended into one ambiguous number.

Cycle time and exception age

Cycle time helps leaders see process friction.

Useful metrics include:

  • request to approval
  • approval to PO
  • PO to receipt
  • receipt to bill
  • bill to approval
  • bill to payment
  • exception age
  • dispute age
  • payment hold age

These metrics matter for COOs because procurement friction can delay operations, inventory, service delivery, and vendor relationships.

They matter for CFOs because old exceptions can distort accruals, close timing, budget visibility, and cash forecasts.

Source systems to map before building

Procure-to-pay reporting usually touches more systems than a basic AP dashboard.

Common sources include:

  • procurement or purchase order tools
  • approval workflow systems
  • accounting or ERP systems
  • accounts payable automation platforms
  • corporate card and expense tools
  • inventory or warehouse management systems
  • project management or service delivery tools
  • contract management systems
  • vendor master records
  • payment processors and bank files
  • budget and forecast spreadsheets
  • manual mapping or exception files

For each source, document:

  • system owner
  • refresh frequency
  • primary identifiers
  • vendor identifiers
  • department, project, location, and account fields
  • request, PO, receipt, bill, and payment dates
  • approval status and approver fields
  • amount fields and currencies
  • recurring spend or contract fields
  • known data quality issues
  • reconciliation point
  • whether the source is operational, finance-approved, forecast, or close-approved

If the broader warehouse scope is still being defined, Data Warehouse Requirements for Small Business is a useful checklist for sources, KPI definitions, owners, refresh needs, and first-phase BigQuery scope.

BigQuery model for procure-to-pay reporting

BigQuery is useful when procurement, AP, receiving, payment, budget, and operations data live in several systems.

The goal is not to dump every table into one dashboard.

The goal is to create a modeled reporting layer that preserves traceability and gives finance and operations one controlled view of spend.

Raw layer

The raw layer stores source extracts with minimal transformation.

Typical raw tables include:

  • purchase requests
  • approval events
  • purchase orders
  • purchase order lines
  • receipt or service completion records
  • vendor bills
  • bill lines
  • credit memos
  • payments
  • vendor records
  • department, project, and account mappings
  • budget and forecast files
  • contract or renewal exports where available

Raw data should make it possible to inspect what changed when a number moves.

Staging layer

The staging layer standardizes source fields.

Common work includes:

  • vendor cleanup
  • department and project normalization
  • chart of accounts mapping
  • currency conversion
  • date standardization
  • status normalization
  • duplicate detection
  • voided, canceled, reversed, or deleted record handling
  • request, PO, bill, and payment identifier cleanup
  • source-system field naming

This layer should make the data usable without hiding the original source context.

Modeled reporting layer

The modeled layer applies business definitions.

Useful model tables may include:

  • vendor dimension
  • department and cost center dimension
  • project or location dimension
  • account and spend category dimension
  • accounting period dimension
  • purchase request fact
  • approval event fact
  • purchase order fact
  • purchase order line fact
  • receipt or completion fact
  • vendor bill fact
  • vendor bill line fact
  • payment fact
  • committed spend snapshot
  • AP aging snapshot
  • recurring spend or renewal schedule
  • budget mapping table
  • exception and reconciliation tables

The model should keep links between records where possible.

A user should be able to trace an operating expense, cash forecast item, or AP balance back to the related request, approval, purchase order, receipt, bill, payment, vendor, department, and source system.

If definitions are already disputed, use a KPI definition framework before expanding the model. Procure-to-pay reporting needs clear formulas, owners, timing rules, inclusion rules, approval logic, and reconciliation points.

Reporting layer

The reporting layer should expose clean views for finance, operations, and leadership.

Examples include:

  • procure-to-pay executive summary
  • requested, approved, committed, billed, and paid spend
  • open purchase orders
  • committed spend by department and vendor
  • unmatched bills
  • receipt not billed
  • bill not received
  • AP aging and payment timing
  • budget impact by owner
  • renewal and recurring vendor spend
  • procure-to-pay exceptions
  • reconciliation status

Dashboard users should not need to rebuild procurement logic from raw approval, PO, bill, and payment tables.

Reconciliation checks before leadership uses the report

Procure-to-pay reporting affects spend control, AP, cash forecast, budget variance, working capital, and close quality. Reconciliation should be visible from the start.

Useful checks include:

  • purchase requests without department, project, or owner
  • approved requests without purchase order
  • purchase orders without vendor mapping
  • open purchase orders with stale expected receipt dates
  • received goods or completed services without vendor bill
  • vendor bills without PO where policy requires one
  • vendor bills with PO amount differences
  • duplicate bills or duplicate payments
  • bills coded to unexpected accounts or departments
  • bills missing approval
  • payments made against disputed bills
  • AP aging not matching the accounting AP report
  • committed spend not included in the cash forecast
  • budget owner missing for committed or billed spend
  • manual adjustments without owner, reason, or expiration date

These are not only technical checks.

They are business controls translated into reporting operations.

The broader data quality checks for finance reporting guide covers freshness, completeness, duplicate handling, reconciliation, owner signoff, and exception workflows in more detail.

How procure-to-pay reporting supports leadership decisions

Procure-to-pay reporting is useful because it connects finance controls to operational execution.

CFO decisions

CFOs can use procure-to-pay reporting to understand:

  • upcoming cash outflows
  • open purchase commitments
  • AP pressure
  • spend approval discipline
  • budget risk before actuals arrive
  • vendor concentration
  • accrual and close risk
  • recurring vendor obligations
  • payment timing options

This gives finance a better bridge between operating expense reporting, working capital reporting, and cash forecasting.

COO decisions

COOs can use procure-to-pay reporting to see whether purchasing supports operations or creates bottlenecks.

Examples include:

  • delayed approvals slowing delivery
  • missing purchase orders blocking receiving
  • vendor delays affecting operations
  • inventory purchases not aligned with demand
  • service providers billing before milestones are accepted
  • operational teams committing spend outside policy
  • stale exceptions that need ownership

This is part of operations reporting, not only finance reporting. Procurement affects delivery, inventory, vendor reliability, cost control, and cash.

Head of Data decisions

Heads of data and analytics leaders can use the procure-to-pay model to prioritize integration work.

The most useful first scope is usually not every procurement field.

It is the set of tables needed to connect:

  • vendor
  • department
  • purchase order
  • receiving or completion
  • bill
  • payment
  • budget
  • exception status

That scope is clear enough to deliver value and structured enough to extend later.

Board and investor reporting decisions

Boards usually do not need detailed procurement workflow metrics.

They may need confidence in:

  • cash forecast assumptions
  • spend control
  • budget discipline
  • vendor concentration
  • working capital pressure
  • margin or inventory risk
  • major recurring obligations

If those topics appear in board materials, procure-to-pay logic should reconcile to the same finance-approved model used for management reporting. The board reporting guide explains how to keep board reporting concise while preserving trusted detail underneath.

Common mistakes to avoid

Mistake 1: treating AP as the full spend pipeline

AP shows obligations after the bill exists.

It does not show all approved purchases, open POs, unbilled receipts, recurring commitments, or operational spend requests.

If finance only sees AP, it may miss spend commitments until too late.

Mistake 2: mixing request, commitment, bill, and payment dates

Request date, approval date, PO date, receipt date, bill date, accounting period, due date, scheduled payment date, and bank posting date all answer different questions.

The report should make timing explicit.

If those dates are blended, budget, cash, AP, and operating expense reporting will keep producing different answers.

Mistake 3: leaving exceptions in email

Procure-to-pay exceptions are normal.

The risk appears when unmatched bills, missing approvals, receipt gaps, vendor mapping issues, and payment holds live only in email or chat.

If an exception affects spend, cash, or close timing, it should eventually be represented in the reporting model.

Mistake 4: ignoring recurring vendor commitments

Many companies can report bills after they arrive but cannot see upcoming renewals, subscription commitments, support contracts, software spend, or planned vendor payments.

That weakens cash planning and budget ownership.

Recurring commitments should be part of the procure-to-pay model where the data is available.

Mistake 5: building too wide in phase one

Procure-to-pay can become a large program if every vendor, contract, approval rule, and edge case is included at once.

A better first phase is to choose the highest-value spend path, such as purchase request to PO to bill to payment for the largest departments or vendors.

Then add receiving, inventory, contract, and renewal detail where the business value is clear.

A practical first phase

For most growing companies, a useful first procure-to-pay reporting phase looks like this:

  1. define the leadership questions the report must answer
  2. choose the first spend category, department group, or vendor segment to model
  3. document the path from request to approval, PO, receipt, bill, payment, and exception
  4. define vendor, department, project, account, period, PO, bill, and payment mappings
  5. load procurement, approval, accounting, payment, and budget data into BigQuery
  6. build request, approval, PO, bill, payment, vendor, department, budget, and exception tables
  7. add committed spend and AP timing views
  8. reconcile modeled AP to accounting and committed spend to open purchase orders
  9. publish a concise leadership view with drill-through exception detail
  10. review exceptions each reporting cycle and expand the model where recurring friction remains

That scope is practical enough to deliver and useful enough to reduce repeated spreadsheet work.

The goal is not to replace every procurement process on day one. The goal is to make spend commitments, vendor obligations, and cash timing easier to see before they become surprises.

If your team needs a reporting foundation that connects procurement, accounting, payments, budgets, and BigQuery models, Agile DataWarehouse offers BigQuery reporting automation and BigQuery implementation for finance and operations leaders who need numbers they can explain.

FAQ

What is procure-to-pay reporting?

Procure-to-pay reporting connects purchase requests, approvals, purchase orders, receiving or service completion, vendor bills, payments, exceptions, and cash timing. It helps finance and operations see how planned spend becomes actual spend and where the process is blocked.

How is procure-to-pay reporting different from accounts payable reporting?

Accounts payable reporting focuses on vendor bills, open balances, due dates, payment status, and AP aging. Procure-to-pay reporting starts earlier, covering purchase requests, approvals, purchase orders, commitments, receiving, bill matching, and payment timing.

What should a procure-to-pay report include?

A procure-to-pay report should include purchase requests, approval status, open purchase orders, committed spend, receiving or service completion, vendor bill status, AP aging, payment timing, exceptions, owners, and reconciliation checks. It should also label which numbers are requested, approved, committed, billed, paid, forecast, or finance-approved.

Can BigQuery support procure-to-pay reporting?

BigQuery can support procure-to-pay reporting by centralizing procurement, approval, receiving, accounting, payment, and budget data. It can then model vendor, department, purchase order, bill, payment, budget, and exception tables with finance-approved definitions and visible reconciliation checks.

Final thought

Procure-to-pay reporting should make spend commitments easier to manage before they become month-end surprises.

Purchase requests, approvals, purchase orders, receipts, vendor bills, payments, and cash timing are connected, but they are not the same thing. A useful reporting model preserves those differences, shows the handoffs, and makes exceptions visible before leadership relies on the numbers.

When procure-to-pay is modeled in BigQuery with clear definitions and reconciliation checks, finance can plan cash with more control, operations can see vendor and purchasing blockers earlier, and leadership can manage spend from one trusted process view.