Data Template: Purchase to Pay - Purchase Order

Coupa
Data Template: Purchase to Pay - Purchase Order

Your Purchase to Pay - Purchase Order Data Template

This template serves as your guide to accurately collect and structure data for process mining your Purchase to Pay - Purchase Order process in Coupa. It details the critical attributes to include, the essential activities to monitor, and provides clear steps for extracting this data, ensuring you have a complete event log.
  • Recommended data attributes
  • Key process activities
  • Coupa data extraction steps
New to event logs? Learn how to create a process mining event log.

Purchase to Pay - Purchase Order Attributes

These are the essential data fields recommended for your event log, enabling a thorough analysis of your Purchase to Pay - Purchase Order process.
5 Required 5 Recommended 12 Optional
Name Description
Activity
ActivityName
The name of the specific event or task that occurred at a point in time within the purchase order lifecycle.
Description

The Activity Name describes a single step in the purchase-to-pay process, such as 'Purchase Order Approved' or 'Goods Receipt Posted'. This sequence of activities forms the process flow for each purchase order.

This attribute is fundamental to process mining, as it is used to construct the process map, discover process variants, and analyze the frequency and sequence of events. It helps identify bottlenecks, rework loops, and deviations from the standard process flow. For example, analyzing the sequence of 'Purchase Order Changed' activities can reveal inefficiencies in order accuracy.

Why it matters

It defines the steps in the process, allowing for the visualization of the process flow and the identification of bottlenecks, rework, and deviations.

Where to get

Derived from event logs, audit trails, or status change records associated with Purchase Order objects in Coupa.

Examples
Purchase Requisition ApprovedPurchase Order SubmittedGoods Receipt PostedInvoice Received for PO
Purchase Order
PurchaseOrderNumber
The unique identifier for a purchase order, serving as the primary case identifier for the process.
Description

The Purchase Order number is the central case identifier that connects all activities from its initial request to the final confirmation of goods or services receipt. Each unique Purchase Order Number represents a single instance of the procurement process.

In process mining analysis, this attribute is crucial for tracing the end-to-end journey of each purchase. It allows analysts to visualize process maps, identify variants, and calculate case-level KPIs, such as the total cycle time for an order. All events and related data are aggregated under this identifier to build a cohesive view of the process.

Why it matters

It is essential for tracking the complete lifecycle of each purchase, enabling the reconstruction of individual process instances for detailed analysis.

Where to get

This is a standard primary key field on the Purchase Order object within Coupa.

Examples
PO-2023-00123PO-2023-00456PO-2023-00789
Start Time
EventTime
The exact timestamp indicating when an activity or event occurred.
Description

Event Time records the date and time that a specific activity was executed. For every activity in the process, there is a corresponding timestamp that marks its occurrence.

This attribute is critical for all time-based analysis in process mining. It is used to calculate cycle times between activities, measure process duration, and identify delays. For instance, the time difference between the 'Purchase Order Drafted' and 'Purchase Order Approved' timestamps is used to calculate the PO Approval Cycle Time KPI.

Why it matters

It provides the temporal context for each event, which is essential for calculating cycle times, analyzing performance, and detecting bottlenecks.

Where to get

Located in the event logs or audit trails of Coupa, typically associated with each status change or action taken on a purchase order.

Examples
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
Last Data Update
LastDataUpdate
The timestamp indicating the last time the data for this process was refreshed.
Description

This attribute records when the dataset was last updated from the source system. It is a metadata field that applies to the entire dataset rather than individual events.

In any analytical dashboard, this timestamp is vital for users to understand the freshness of the data they are viewing. It provides confidence that the insights are based on recent information and helps manage user expectations about data currency. It is typically displayed prominently in dashboards.

Why it matters

Informs users about the timeliness of the data, ensuring they understand how current the process analysis and KPIs are.

Where to get

This timestamp is generated and stored by the data extraction and loading (ETL) pipeline when it runs.

Examples
2023-11-01T05:00:00Z
Source System
SourceSystem
The system from which the process data was extracted.
Description

This attribute identifies the originating information system where the event data was recorded. For this process, the value would consistently be 'Coupa'.

In enterprise environments where data may come from multiple systems (e.g., Coupa for procurement, another ERP for invoicing), this attribute helps differentiate data sources. It ensures clarity in data lineage and can be used to filter analysis for a specific system's view of the process.

Why it matters

It provides crucial context about data origin, ensuring traceability and enabling proper data governance, especially in multi-system landscapes.

Where to get

This is a static value that is typically added during the data extraction and transformation process to label the dataset.

Examples
Coupa
Department
Department
The business department or cost center to which the purchase order is charged.
Description

The Department attribute specifies the organizational unit that initiated the purchase or will bear its cost. This is often linked to the requester or the cost center information on the purchase order line items.

This dimension is essential for segmenting process analysis and KPIs. It allows managers to compare process efficiency, compliance, and spending patterns across different parts of the organization. For example, the 'Spend Analysis by Purchase Category' dashboard uses Department to show how different business units are spending their budgets.

Why it matters

It allows for process and spend analysis to be filtered and compared across different business units, revealing variations in efficiency and compliance.

Where to get

Available on the Purchase Order header or line items in Coupa, often linked to a Cost Center or organizational unit.

Examples
MarketingInformation TechnologyOperationsFinance
Purchase Category
PurchaseCategory
The classification of the goods or services being purchased, such as IT Hardware or Professional Services.
Description

Purchase Category, also known as Commodity or Material Group, is a classification used to group similar types of purchases. This structured data allows for systematic analysis of spending and procurement processes.

In process mining, this attribute is a powerful dimension for filtering and segmentation. The 'Spend Analysis by Purchase Category' dashboard relies on it to break down spending patterns. It can also reveal if certain categories (e.g., complex services) have longer cycle times or higher change rates than others (e.g., standard office supplies).

Why it matters

It enables spend and process analysis by category, helping to identify procurement patterns, negotiate with vendors, and tailor process controls.

Where to get

Typically found at the Purchase Order line item level in Coupa, often linked to a commodity code or purchasing catalog.

Examples
IT HardwareOffice SuppliesProfessional ServicesMarketing Materials
Total Order Amount
TotalOrderAmount
The total monetary value of the purchase order.
Description

This attribute represents the total cost of all goods and services specified in the purchase order, expressed in a specific currency. It is a case-level attribute that applies to the entire order.

This financial data is crucial for spend analysis and for prioritizing process improvement efforts. High-value orders may warrant more scrutiny or different approval paths. It is used directly in the 'Spend Analysis by Purchase Category' dashboard and is a component for calculating the 'Spend by Non-Preferred Vendor Ratio' KPI.

Why it matters

Provides the financial context for each purchase, enabling spend analysis, prioritization of high-value orders, and assessment of financial impact.

Where to get

Available on the Purchase Order header in Coupa, typically as 'Total' or 'Grand Total'.

Examples
1500.00250.7512500.50
User
User
The user ID or name of the person who performed the activity, such as an approver or requester.
Description

This attribute identifies the individual responsible for executing a specific event in the process. This could be the person who drafted the order, the manager who approved it, or the clerk who posted the goods receipt.

Analyzing performance by user helps identify training needs, high-performing individuals, and workload distribution. For example, the 'PO Approval Cycle Time Performance' dashboard uses this attribute to break down approval times by specific approvers, highlighting who may be a bottleneck in the process.

Why it matters

It enables analysis of process performance by individual or role, helping to identify bottlenecks, training opportunities, and resource allocation issues.

Where to get

Associated with each event in the Purchase Order audit trail or history logs in Coupa. Fields like 'Created By', 'Approved By', or 'Updated By' are common sources.

Examples
j.doea.smithm.jones
Vendor Name
VendorName
The name of the supplier or vendor from whom goods or services are being purchased.
Description

The Vendor Name identifies the external party supplying the items on the purchase order. This information is fundamental to procurement analytics.

Analyzing process performance by vendor is critical for supplier relationship management. It helps in evaluating 'Supplier Lead Time Performance', identifying delays in 'Goods Receipt Process Delays', and assessing supplier quality through 'Goods Return Rate'. This attribute is also key for calculating the 'Spend by Non-Preferred Vendor Ratio' KPI.

Why it matters

Enables supplier performance analysis, helping to optimize supplier selection, negotiate better terms, and identify high- or low-performing vendors.

Where to get

A standard field on the Purchase Order header in Coupa, linked to the Supplier Master Data.

Examples
Global Office SuppliesTech Solutions Inc.Advanced Industrial PartsCreative Marketing Agency
Change Reason
ChangeReason
The reason provided for a change made to a purchase order after its initial creation.
Description

This attribute captures the justification for why a purchase order was modified, for example, 'Quantity updated' or 'Price correction'. This information is often recorded in the audit trail when a user executes a 'Purchase Order Changed' activity.

Understanding why orders are changed is key to the 'Purchase Order Change Analysis' dashboard. It helps differentiate between unavoidable changes (e.g., vendor stock issues) and preventable ones (e.g., incorrect initial data entry), guiding efforts to improve order accuracy and reduce the 'Purchase Order Change Rate' KPI.

Why it matters

Explains the root causes of PO changes, enabling targeted actions to improve first-time order accuracy and reduce process rework.

Where to get

Often found in the audit logs or comments associated with the change events for a Purchase Order in Coupa.

Examples
Price update from vendorDelivery date adjustedCorrected item code
Currency
Currency
The currency code for the monetary values on the purchase order.
Description

This attribute specifies the currency (e.g., USD, EUR, GBP) in which the Total Order Amount is denominated. It is essential for correctly interpreting financial data in a global organization.

For multinational companies, analyzing spend without considering currency can be misleading. This attribute allows for proper currency conversion and consistent financial reporting within dashboards, ensuring that values are compared on a like-for-like basis.

Why it matters

Ensures accurate financial analysis and reporting in multinational contexts by providing the necessary information for currency conversion.

Where to get

A standard field on the Purchase Order header in Coupa.

Examples
USDEURGBPJPY
Is Delivery On Time
IsDeliveryOnTime
A calculated flag indicating if the goods were received on or before the requested delivery date.
Description

This boolean attribute is calculated by comparing the timestamp of the 'Goods Receipt Posted' event with the 'RequestedDeliveryDate'. It is set to true if the receipt date is on or before the requested date.

This flag directly supports the 'Supplier Delivery Date Adherence' KPI and the 'Delivery Date Variance and Returns' dashboard. It provides a clear, binary outcome for on-time performance that is easy to aggregate and visualize, helping to quickly identify performance issues with vendors or internal receiving processes.

Why it matters

Provides a clear, binary metric for delivery performance, simplifying the calculation of on-time delivery KPIs and trend analysis.

Where to get

Calculated during data transformation by comparing 'RequestedDeliveryDate' with the timestamp of the 'Goods Receipt Posted' activity.

Examples
truefalse
Is First Pass Approval
IsFirstPassApproval
A calculated flag that is true if the PO was approved without any changes after being drafted.
Description

This boolean flag is set to true if a purchase order's journey from 'Purchase Order Drafted' to 'Purchase Order Approved' does not contain any 'Purchase Order Changed' or 'Purchase Order Rejected' activities in between.

This attribute directly measures the 'First-Pass PO Approval Rate' KPI. A high rate indicates efficient and accurate initial processing. Analyzing the cases where this flag is false can help uncover reasons for rework and improve the upfront data quality of purchase orders.

Why it matters

Directly measures the efficiency of the initial creation and approval process, highlighting the volume of orders that flow through without rework.

Where to get

Calculated during data transformation by analyzing the sequence of events for each PurchaseOrderNumber.

Examples
truefalse
Is Preferred Vendor
IsPreferredVendor
A boolean flag indicating if the purchase was made from a preferred or strategic vendor.
Description

This flag identifies whether the vendor on the purchase order is part of a pre-approved list of strategic suppliers. This is typically determined by cross-referencing the vendor name or ID with a master list of preferred vendors.

This attribute is essential for strategic sourcing and spend management initiatives. It is used to calculate the 'Spend by Non-Preferred Vendor Ratio' KPI, which helps organizations monitor and control maverick buying and consolidate spend with key partners to leverage volume discounts and better terms.

Why it matters

Helps monitor procurement policy compliance and strategic sourcing goals by tracking spend with preferred versus non-preferred suppliers.

Where to get

This is often not a standard field in Coupa but is derived by comparing the Vendor ID on the PO with an external list of preferred vendors.

Examples
truefalse
Is Rework
IsRework
A calculated flag that identifies if a purchase order has undergone a change activity.
Description

This boolean flag is set to true for any purchase order that has at least one 'Purchase Order Changed' event in its history. It is a case-level attribute derived from the event log.

This attribute simplifies the calculation of KPIs like the 'Purchase Order Change Rate'. It allows for easy filtering and segmentation of the data to compare processes for orders with and without rework, helping to quantify the impact of changes on cycle time and cost. It is a core component of the 'Purchase Order Change Analysis' dashboard.

Why it matters

Simplifies the analysis of rework by allowing easy filtering and aggregation for all purchase orders that have been changed at least once.

Where to get

Calculated during data transformation by checking for the existence of a 'Purchase Order Changed' activity for each PurchaseOrderNumber.

Examples
truefalse
Processing Time
ProcessingTime
The duration of an activity, representing the time a user actively worked on a task.
Description

Processing time, sometimes called 'service time', is the time spent actively working on a task. It is distinct from waiting time. For example, it could measure the time between when a user opens a PO approval task and when they submit the approval.

This metric provides a more accurate view of user effort compared to cycle time, which includes waiting periods. Analyzing processing time helps in capacity planning, workload balancing, and identifying tasks that are inherently time-consuming. It requires both a start and end time for a single activity, which is not always available.

Why it matters

Helps distinguish between active work time and waiting time, providing better insights into resource efficiency and task complexity.

Where to get

Calculated if both start and end timestamps for a single activity are available in the Coupa audit logs. This is often not standard.

Examples
3600120900
Purchase Requisition Number
PurchaseRequisitionNumber
The unique identifier for the purchase requisition that preceded the purchase order.
Description

This attribute links a purchase order back to its originating purchase requisition. A single requisition may lead to one or more purchase orders.

This linkage is essential for analyzing the full 'Requisition-to-Order' cycle time. By connecting the requisition's creation event with the purchase order's creation and sending events, organizations can measure the efficiency of their entire procurement initiation process, from request to fulfillment.

Why it matters

It connects the request and ordering phases of the process, enabling the analysis of the requisition-to-order cycle time and conversion rates.

Where to get

This is typically a reference field on the Purchase Order line items in Coupa, linking back to the source requisition.

Examples
PR-2023-00098PR-2023-00152PR-2023-00341
Receiving Location
ReceivingLocation
The physical location, such as a warehouse or office, where the goods are to be delivered.
Description

The Receiving Location specifies the destination for the goods ordered on the PO. This could be a specific warehouse, plant, or office address.

This attribute is used to analyze logistics and receiving performance across different sites. The 'Goods Receipt Process Delays' dashboard can be filtered by this attribute to determine if certain locations are slower at processing incoming shipments, which can help pinpoint operational inefficiencies or resource constraints at specific sites.

Why it matters

Allows for location-based analysis of the receiving process, highlighting performance differences between warehouses, plants, or offices.

Where to get

This information is part of the 'Ship-To' address on the Purchase Order in Coupa.

Examples
Warehouse A - ChicagoBuilding 5 - London OfficeFrankfurt Plant
Rejection Reason
RejectionReason
The reason provided when a purchase requisition or purchase order is rejected during an approval step.
Description

When an approver rejects a purchase order, they often provide a reason for the rejection. This attribute captures that textual explanation, such as 'Incorrect budget code' or 'Exceeds spending limit'.

Analyzing rejection reasons provides direct insight into the root causes of rework and process failures. This qualitative data can be used to identify common errors in the requisitioning process, leading to targeted training or system improvements to prevent future rejections and improve the first-pass approval rate.

Why it matters

Provides direct, actionable insights into why purchase orders are rejected, helping to address root causes of process rework and delays.

Where to get

Typically captured in the comments or notes field associated with the 'Purchase Order Rejected' or 'Purchase Requisition Rejected' activity in Coupa's approval workflow.

Examples
Duplicate requestBudget not approvedIncorrect vendor selected
Requested Delivery Date
RequestedDeliveryDate
The date on which the requester has asked for the goods or services to be delivered.
Description

This attribute is the target delivery date specified by the business user during the requisition process. It represents the business's expectation for when the order should be fulfilled.

This date is a critical benchmark for measuring supplier and internal performance. It is directly used to calculate the 'Supplier Delivery Date Adherence' KPI by comparing it to the actual 'Goods Receipt Posted' date. The 'Delivery Date Variance and Returns' dashboard visualizes deviations between this requested date and the actual delivery, helping to manage expectations and improve forecasting.

Why it matters

Serves as a key performance baseline for measuring on-time delivery from vendors and the efficiency of the internal receiving process.

Where to get

A standard field on the Purchase Order line item in Coupa.

Examples
2023-11-152023-12-012024-01-10
Requester Name
RequesterName
The name of the individual who initially requested the goods or services.
Description

This attribute identifies the employee who created the purchase requisition that led to the purchase order. The requester is the business user with the need, who may be different from the buyer or approver.

Analyzing process behavior by requester helps identify patterns related to specific users or departments. The 'Purchase Order Change Analysis' dashboard uses this to see if certain requesters have a higher frequency of order changes, which could indicate a need for better training on specification requirements.

Why it matters

Helps identify the business origin of a purchase, enabling analysis of procurement behavior and accuracy at the requester level.

Where to get

This information is usually stored on the source Purchase Requisition and carried over to the Purchase Order in Coupa.

Examples
Alice CooperBob DylanCharlie Parker
Required Recommended Optional

Purchase to Pay - Purchase Order Activities

These are the crucial process steps and milestones to track in your event log for accurate discovery and analysis of your P2P operations.
6 Recommended 11 Optional
Activity Description
Goods Receipt Posted
This is the formal confirmation that goods have been received, inspected, and accepted. This event updates inventory records and signals that the vendor's obligation for this delivery has been met.
Why it matters

This critical milestone marks the end of the supplier lead time and is used to measure delivery date adherence. Delays in posting receipts can obscure visibility into actual inventory levels.

Where to get

This is a core transaction in Coupa, recorded on the Receipt object. The event is captured from the timestamp when the receipt's status becomes 'Posted' or 'Received'.

Capture

Logged when the goods receipt transaction is finalized in the system.

Event type explicit
Purchase Order Approved
This milestone signifies that the purchase order has completed its internal approval workflow and is authorized for issuance to the vendor. This is typically the final approval step in a multi-step process.
Why it matters

This is a critical milestone for calculating PO approval cycle times and identifying approval bottlenecks. It also serves as a key compliance checkpoint.

Where to get

Captured from the Purchase Order's approval history log in Coupa. The timestamp of the final approval action provides the event time.

Capture

Logged in the approval history when the final approver completes their task.

Event type explicit
Purchase Order Canceled
This activity represents the cancellation of a purchase order before it was completed. A cancellation can occur at various stages, for example, if the request is no longer valid or if the PO was created in error.
Why it matters

As an alternative process ending, tracking cancellations is important for understanding process fallout and identifying reasons for abandoned purchase requests.

Where to get

This is inferred from a status change on the Purchase Order object to 'Canceled'. The timestamp of this status change is used as the event time.

Capture

Derived from the timestamp of the status change to 'Canceled'.

Event type inferred
Purchase Order Closed
This is the final activity, signifying that the purchase order is complete. The PO is considered closed when it has been fully received and fully invoiced, and no further transactions are expected.
Why it matters

This activity officially ends the PO lifecycle. Analyzing the time to close can reveal inefficiencies in final reconciliation and record-keeping.

Where to get

This is inferred from a status change on the Purchase Order object to 'Closed'. This status is often set automatically by Coupa based on business rules regarding receiving and invoicing tolerances.

Capture

Derived from the timestamp of the status change to 'Closed'.

Event type inferred
Purchase Order Sent to Vendor
This activity marks the point when the approved purchase order is officially transmitted to the vendor, for example, via email or through the Coupa Supplier Portal. This event transitions the PO from an internal document to an external commitment.
Why it matters

This is a key milestone that concludes the internal Requisition-to-Order cycle and begins the supplier lead time. It is vital for measuring both internal efficiency and supplier performance.

Where to get

Often inferred from a status change on the PO to 'Ordered' or 'Sent'. Coupa may also have a specific 'last_exported_at' or 'sent_to_supplier_at' timestamp on the PO record.

Capture

Derived from the timestamp of the status change to 'Ordered' or a specific transmission timestamp field.

Event type inferred
Purchase Requisition Created
This activity marks the creation of a purchase requisition, which is the formal request for goods or services that precedes a purchase order. In Coupa, this is an explicit event captured when a user saves and submits a new requisition document.
Why it matters

As the typical starting point of the procurement process, this activity is essential for measuring the full Requisition-to-Order cycle time and understanding upstream process efficiency.

Where to get

This event corresponds to the creation record in the Purchase Requisitions object or table in Coupa. The timestamp can be found in the 'created_at' or equivalent system-generated creation date field.

Capture

Directly logged upon creation of a new requisition record.

Event type explicit
Goods Receipt Initiated
This activity represents the start of the receiving process, such as when a receipt document is created in Coupa upon the physical arrival of goods. The goods have not yet been formally posted to inventory or confirmed as received.
Why it matters

This event is the starting point for measuring the Goods Receipt Processing Time KPI. It helps differentiate between the time goods are waiting on the dock and the time spent on system processing.

Where to get

This can be inferred from the creation timestamp of a receipt document that is in a 'Draft' or 'Pending' status. It precedes the final posting of the receipt.

Capture

Derived from the creation timestamp of a receipt record in a non-posted state.

Event type inferred
Goods Returned
This activity is recorded when previously received goods are sent back to the vendor. This is typically due to quality issues, damage, or incorrect shipments.
Why it matters

Tracking returns is essential for calculating the Goods Return Rate and identifying problems with supplier quality or order accuracy. High return rates often indicate costly process failures.

Where to get

This is captured from a 'Return to Supplier' transaction or a negative receipt transaction in Coupa. The timestamp of this transaction serves as the event time.

Capture

Logged when a return transaction linked to the original PO/receipt is created.

Event type explicit
Invoice Received for PO
This event marks the receipt and entry of a supplier's invoice that references the purchase order. It signifies the start of the invoice processing and payment phase of the P2P cycle.
Why it matters

While part of the AP process, linking the invoice receipt to the PO provides an end-to-end view of the transaction lifecycle and helps analyze the gap between delivery and invoicing.

Where to get

Captured from the creation timestamp of the Invoice document in Coupa, where the invoice is matched against the corresponding Purchase Order number.

Capture

Logged upon creation of an invoice record linked to the PO.

Event type explicit
Purchase Order Changed
This event represents any modification made to the purchase order after it was initially drafted. In Coupa, changes are often tracked through versioning of the PO document.
Why it matters

Tracking changes is crucial for KPIs like the Purchase Order Change Rate and Non-Conforming PO Rate. Frequent changes indicate process instability or inaccurate initial requests.

Where to get

Can be inferred by tracking different versions of a Purchase Order. Each new version number greater than the first indicates a change, with the creation date of the new version serving as the event timestamp.

Capture

Inferred from the creation timestamp of a new PO version.

Event type inferred
Purchase Order Drafted
This event represents the initial creation of the Purchase Order document in the system, often from an approved requisition. At this stage, the PO is an internal draft and has not yet been submitted for approval or sent to the vendor.
Why it matters

This activity starts the clock for measuring the PO Approval Cycle Time KPI. It is the first formal step in the purchase order's own lifecycle.

Where to get

This corresponds to the creation timestamp of the Purchase Order record in Coupa, which is typically found in a field like 'created_at'.

Capture

Captured from the system-generated creation timestamp of the PO record.

Event type explicit
Purchase Order Rejected
This activity occurs when an approver rejects the purchase order during the approval workflow. The PO is then typically sent back to the creator for revision or cancellation.
Why it matters

Analyzing rejections helps uncover issues with data quality, policy violations, or training gaps. It highlights rework loops that cause significant process delays.

Where to get

This is an explicit event captured in the Purchase Order's approval history log in Coupa. The log will show a 'Reject' action with a corresponding timestamp.

Capture

Logged in the approval history with a 'Reject' status.

Event type explicit
Purchase Order Submitted
After a purchase order is drafted, it is formally submitted into the approval workflow. This is a distinct user action that moves the PO from a draft state to a pending approval state.
Why it matters

This event distinguishes the drafting time from the time the PO is actually awaiting approval. It provides a clearer picture of user behavior and process handoffs.

Where to get

Inferred from a status change on the Purchase Order object, for example from 'draft' to 'pending approval'. The timestamp of this specific status change is used.

Capture

Derived from the timestamp of the status change to 'pending approval'.

Event type inferred
Purchase Requisition Approved
A purchase requisition undergoes an approval workflow before it can be converted into a purchase order. This event signifies the final approval of the requisition, making it ready for ordering.
Why it matters

Tracking requisition approvals helps identify bottlenecks in the pre-ordering phase. Delays here directly impact how quickly a purchase order can be issued.

Where to get

This is typically captured from the approval history of the requisition object in Coupa. The final approval action will have a corresponding timestamp and user.

Capture

Logged in the approval history when the final approver takes action.

Event type explicit
Quality Inspection Performed
This event indicates that a received item has undergone and passed a quality inspection. This may be a separate step after the initial goods receipt is posted, depending on the company's process.
Why it matters

This activity is key to measuring the efficiency of the quality control process. Delays here can create bottlenecks between receiving and availability for use.

Where to get

This may be recorded as a status change on the receipt line item or through a separate inspection object in Coupa. Its availability depends on whether the quality module or a custom workflow is used.

Capture

Inferred from a status change on the receipt or a timestamp on a related inspection record.

Event type inferred
Services Confirmation Entered
For services-based purchase orders, this activity is the equivalent of a goods receipt. It confirms that a service has been rendered according to the terms of the PO.
Why it matters

Tracking service confirmations is crucial for managing spend on services and ensuring that payments are only made for work that has been verified as complete.

Where to get

This event is captured from the creation or approval of a service receipt or service entry sheet linked to the Purchase Order in Coupa.

Capture

Logged upon the creation and approval of a service entry sheet.

Event type explicit
Vendor Acknowledged Order
This event signifies that the vendor has received and confirmed the purchase order. This confirmation is often captured electronically through a supplier portal like the Coupa Supplier Portal (CSP).
Why it matters

Vendor acknowledgments provide certainty that an order is being processed, improving the accuracy of delivery forecasting and reducing supply chain uncertainty.

Where to get

This information is typically available on the Purchase Order if the vendor uses the Coupa Supplier Portal to perform an 'Acknowledge' action. The timestamp of this action is used.

Capture

Logged when a vendor performs the 'Acknowledge' action in the supplier portal.

Event type explicit
Recommended Optional

Extraction Guides

How to get your data from Coupa