> Continuous Process Improvement > Purchase to Pay Requisition > Coupa > Data Template

Your Purchase to Pay - Requisition Data Template

Coupa

Purchase to Pay - Requisition Attributes (22) Purchase to Pay - Requisition Activities (12) Extraction Guides (3)

Your Purchase to Pay - Requisition Data Template

This comprehensive data template provides a structured approach for collecting the necessary information to analyze your Purchase to Pay, Requisition process. It outlines the essential attributes and activities required for a robust event log. You will also find guidance on extracting this data effectively from your Coupa system.

Recommended attributes for comprehensive analysis
Key process activities to track
Practical data extraction guidance

New to event logs? Learn how to create a process mining event log.

Download Template

Purchase to Pay - Requisition Attributes

These are the recommended data fields to include in your event log for a comprehensive analysis of your Purchase to Pay, Requisition process.

5 Required 5 Recommended 12 Optional

	Name	Description
	Activity Name ActivityName	The name of the specific business activity or event that occurred at a point in time for the requisition.
Description This attribute records the distinct steps in the purchase requisition lifecycle. Examples include 'Requisition Created', 'Approval Step Approved', and 'Requisition Sourced'. Each activity represents a specific milestone or action taken on the requisition. Analyzing the sequence and frequency of these activities is fundamental to process mining, as it allows for the visualization of process maps, identification of common pathways, and detection of deviations from the standard procedure. Why it matters It defines the steps in the process map, making it possible to visualize and analyze the flow of requisitions. Where to get This is typically derived from event logs, status change records, or audit trails within the Coupa system. It may require mapping from status fields or action codes. Examples Requisition CreatedRequisition SubmittedApproval Step ApprovedRequisition RejectedPurchase Order Created
	Event Time EventTime	The precise date and time when the activity occurred.
Description Event Time, or the timestamp, captures the exact moment an activity was recorded for a purchase requisition. This data is critical for chronological ordering of events to build the process flow. It is the basis for all time-based analysis, including calculating cycle times, identifying bottlenecks by measuring the duration between activities, and understanding process performance over different time periods. Accurate and granular timestamps are essential for meaningful process analysis. Why it matters This timestamp is crucial for ordering events correctly and calculating all duration-based metrics, such as cycle times and bottlenecks. Where to get This information is captured in the audit trail or history records for each requisition in Coupa, often as a 'created_at' or 'updated_at' field for each action. Examples 2023-10-26T10:00:00Z2023-10-26T11:35:10Z2023-10-27T14:22:05Z
	Purchase Requisition ID PurchaseRequisitionId	The unique identifier for each purchase requisition, serving as the primary case identifier for the process.
Description The Purchase Requisition ID is the central key that links all activities related to a single request for goods or services. Each requisition is assigned a unique ID upon creation, which remains constant throughout its lifecycle. This allows for end-to-end tracking of the requisition, from its initial creation and submission, through all approval or rejection steps, to its final sourcing and closure. In process mining, every event log entry is tied to this ID, enabling the reconstruction of the complete journey for each case. Why it matters This is the essential Case ID that connects all process steps, enabling a complete analysis of the requisition's lifecycle from start to finish. Where to get This is a primary key field found in Coupa's Requisitions module and related data exports. Examples PR-102934PR-102935PR-102936
	Last Data Update LastDataUpdate	The timestamp indicating the last time the data was refreshed from the source system.
Description This attribute records the date and time of the most recent data extraction from Coupa. It provides transparency into the freshness of the data being analyzed. Knowing the data's recency is critical for users to understand if the insights reflect the current operational state or an earlier point in time. This is particularly important for dashboards that monitor ongoing operations. Why it matters Informs users about the freshness of the data, ensuring they understand the time frame of the analysis and make decisions based on up-to-date information. Where to get This timestamp is generated and added by the data pipeline or ETL tool at the end of a successful data extraction run. Examples 2024-05-21T02:00:00Z
	Source System SourceSystem	Identifies the source system from which the data was extracted.
Description This attribute specifies the system of record where the process data originated. For this analysis, the value will consistently be 'Coupa'. Including this field is a best practice, especially in environments where data might be merged from multiple systems. It provides essential context about data lineage and helps in managing data governance and quality rules. Why it matters Provides clear data lineage, which is crucial for data governance and when blending data from multiple enterprise systems. Where to get This is typically a static value added during the data extraction and transformation process to label the origin of the dataset. Examples Coupa
	Approver Approver	The user or group responsible for an approval activity.
Description This attribute identifies the specific individual or approval group assigned to an approval step. It is populated for activities like 'Approval Step Started', 'Approval Step Approved', and 'Approval Step Rejected'. Analyzing data by approver is key to building the 'Approver Performance and Load' dashboard. It helps measure individual approval times, identify bottlenecks caused by specific approvers, and assess workload distribution. Why it matters Crucial for analyzing approver performance, workload balancing, and identifying bottlenecks related to specific individuals or approval groups. Where to get This information is found in the approval chain details associated with each requisition in Coupa. It may require joining with User data. Examples David MillerFinance Approvers L2Susan Chen
	Department Department	The business department or cost center to which the requisition is charged.
Description The Department attribute links each requisition to a specific organizational unit or cost center. This is a critical dimension for comparative analysis. It allows dashboards and KPIs to be filtered and segmented by department, enabling managers to compare approval cycle times, rejection rates, and compliance across different parts of the organization. This helps pinpoint department-specific issues or best practices. Why it matters Enables comparison of process KPIs like cycle time and rejection rates across different business units, highlighting areas for improvement. Where to get This is a standard field on the Requisition object in Coupa, often associated with the requester's user profile or specified on the requisition line items. Examples MarketingIT OperationsFacilitiesResearch & Development
	Requester Requester	The employee who created and submitted the purchase requisition.
Description This attribute identifies the individual who initiated the request. Analyzing data by requester helps identify patterns related to specific users, such as high amendment rates or frequent rejections, which may indicate a need for additional training. It is also used to analyze requisition volumes and process behavior for different users or user groups. Why it matters Allows analysis of process behavior by user, helping to identify training needs and understand how different individuals interact with the process. Where to get Available as a standard field on the Requisition object in Coupa, often linked to the User object and named 'requester' or 'created_by'. Examples Alice JohnsonBob SmithCharlie Brown
	Requisition Status RequisitionStatus	The current or final status of the purchase requisition.
Description This attribute indicates the overall state of the requisition at the time of data extraction or its final outcome. Common statuses include 'Pending Approval', 'Approved', 'Rejected', 'Withdrawn', and 'Closed'. This is a key dimension for filtering and analysis. It is used to calculate approval and rejection rates, monitor the current workload of open requisitions, and understand the final disposition of requests. Why it matters Essential for understanding requisition outcomes, calculating approval and rejection rates, and monitoring the current state of in-flight requisitions. Where to get This is a standard field on the Purchase Requisition object in Coupa, often named 'status' or 'state'. Examples Pending ApprovalApprovedRejectedWithdrawnClosed
	Total Amount TotalAmount	The total monetary value of the purchase requisition.
Description This attribute represents the total cost of all goods and services requested in the requisition. The amount is a crucial factor in process analysis as it often influences the complexity of the approval workflow; higher value requisitions typically require more approval steps. Analyzing process metrics by value bands (e.g., <$1000, $1000-$10000) can reveal how the process handles requisitions of different financial significance. Why it matters Helps analyze how the process varies for requisitions of different values, as higher amounts often trigger more complex approval workflows. Where to get This is a standard field on the header of the Requisition object in Coupa, typically named 'total' or 'total_amount'. Examples 500.0012550.7599.99
	Approval Step Count ApprovalStepCount	The total number of approval steps a requisition has gone through.
Description This calculated attribute counts the number of distinct 'Approval Step Approved' activities for each requisition. It helps quantify the complexity of the approval workflow for each case. This is the basis for the 'Average Number of Approval Steps' KPI and is useful for identifying requisitions that follow unusually long or complex approval paths, which may indicate a need for workflow simplification. Why it matters Quantifies the complexity of the approval workflow for each requisition, helping to identify overly complex paths that need streamlining. Where to get This metric is calculated in the process mining tool by counting the occurrences of 'Approval Step Approved' for each Case ID. Examples 253
	Approval Step Duration ApprovalStepDuration	The time a requisition spent waiting at a single approval step.
Description This calculated metric measures the duration between an 'Approval Step Started' activity and its corresponding 'Approval Step Approved' or 'Approval Step Rejected' activity. It isolates the wait time at each distinct stage of the approval chain. This is crucial for the 'Critical Approval Step Bottlenecks' dashboard, as it pinpoints exactly which approvers or approval stages are causing the most significant delays in the overall process. Why it matters Pinpoints specific bottlenecks within the approval workflow by measuring the wait time at each individual step, rather than just the total cycle time. Where to get Calculated in the process mining tool by finding the time difference between 'Approval Step Started' and the subsequent terminal approval event (Approved/Rejected). Examples 1.2 days4 hours3.8 days
	Approval Workflow Path ApprovalWorkflowPath	An identifier for the specific approval chain or workflow template applied to the requisition.
Description This attribute identifies the predefined sequence of approvers that a requisition is supposed to follow. It is determined by business rules, often based on factors like amount, department, and requisition type. Analyzing this attribute is central to the 'Requisition Policy Compliance' dashboard. By comparing the actual sequence of approvers to the assigned workflow path, it becomes possible to detect deviations, measure conformance rates, and identify unmanaged exceptions. Why it matters Enables compliance analysis by allowing a comparison between the expected and actual approval steps, highlighting process deviations. Where to get Consult Coupa documentation. This may be derived from the name of the approval chain or workflow rule that was triggered for the requisition. Examples Standard Approval <$5kIT Hardware Approval >$10kCapital Expense CFO Review
	Commodity Commodity	The high-level category of the goods or services being requested.
Description The Commodity attribute provides a standardized classification for the items on a requisition, such as 'Office Supplies', 'Computer Hardware', or 'Marketing Services'. This allows for analysis of purchasing patterns and process variations based on what is being bought. Certain commodities may have specialized approval requirements or sourcing strategies, and analyzing the process by commodity can help optimize procurement for different spending categories. Why it matters Helps in analyzing spend categories and understanding if process behavior, such as approval times, varies by the type of goods or services purchased. Where to get This is a standard field in Coupa, typically available at the requisition line item level. It may need to be aggregated to the header level. Examples Office SuppliesComputer HardwareMarketing ServicesTravel
	Currency Currency	The currency code for the total amount of the requisition.
Description This attribute specifies the currency (e.g., USD, EUR, GBP) in which the requisition's Total Amount is denominated. It is essential context for any financial analysis, especially for multinational organizations that operate with multiple currencies. It ensures that monetary values are interpreted correctly and allows for proper conversion and aggregation in financial reporting and dashboards. Why it matters Provides necessary context for the 'Total Amount' attribute, ensuring accurate financial analysis in multi-currency environments. Where to get This is a standard field on the Requisition object in Coupa, usually named 'currency_code' or similar. Examples USDEURGBP
	Is Amended IsAmended	A boolean flag that is true if the requisition was amended one or more times after its initial submission.
Description This calculated attribute is a simple flag (True/False) that indicates whether a 'Requisition Amended' activity occurred for a given case. It simplifies analysis and filtering by allowing users to easily isolate requisitions that required changes. This is used to calculate the Requisition Amendment Rate KPI and to power the 'Requisition Amendment Volume' dashboard, helping to identify the root causes of rework and improve first-time quality. Why it matters Simplifies the calculation of the amendment rate KPI and allows for easy segmentation of cases that required rework versus those that did not. Where to get This is calculated in the process mining tool by checking for the existence of a 'Requisition Amended' activity within the event log for each case. Examples truefalse
	Purchase Order ID PurchaseOrderId	The identifier of the purchase order that was created from the approved requisition.
Description Once a requisition is fully approved and sourced, a purchase order is typically created. This attribute stores the ID of that resulting PO. It serves as a crucial link between the upstream Requisition process and the downstream Purchase Order process. It enables the calculation of the 'Time from Requisition Approval to PO Creation' KPI and allows for a broader, end-to-end analysis of the entire Purchase-to-Pay cycle. Why it matters Links the requisition to the subsequent purchase order, enabling analysis of the handoff time and facilitating a broader end-to-end P2P view. Where to get This is a standard field on the Requisition object in Coupa that gets populated after the PO is created. Examples PO-45000123PO-45000124PO-45000125
	Rejection Reason RejectionReason	The reason provided by an approver when a requisition or an approval step is rejected.
Description When an approver rejects a requisition, they often provide a reason for the decision. This attribute captures that textual explanation. Analyzing rejection reasons provides direct, qualitative feedback on why requisitions fail. This insight is invaluable for root cause analysis, helping to identify common issues like incorrect coding, lack of budget, or insufficient justification, which can then be addressed through training or process improvements. Why it matters Provides direct insight into the root causes of process failures, helping to identify areas for user training or process clarification. Where to get This information is typically captured in the comments or notes field associated with a 'Rejected' status change in the requisition's approval history. Examples Incorrect cost centerExceeds budget for this quarterDuplicate requestInsufficient justification provided
	Requisition Approval Cycle Time RequisitionApprovalCycleTime	The total time elapsed from when a requisition is first submitted to when it receives final approval.
Description This is a calculated metric that measures the duration of the core approval process. It is computed by finding the time difference between the 'Requisition Submitted' activity and the 'Requisition Approved' activity for each case. This is one of the most important KPIs for this process, as it directly quantifies the efficiency of the approval workflow. It is used in multiple dashboards to track performance, identify bottlenecks, and measure the impact of process improvement initiatives. Why it matters This is a primary KPI for measuring process efficiency. It quantifies the time taken for approvals and is essential for identifying bottlenecks. Where to get This metric is calculated in the process mining tool by subtracting the timestamp of 'Requisition Submitted' from the timestamp of 'Requisition Approved'. Examples 2.5 days8 hours15.2 days
	Requisition Type RequisitionType	The category or type of the requisition, such as 'Capital Expense', 'Operational Expense', or 'Software'.
Description Requisition Type is a classification that helps categorize requisitions based on their business purpose or the nature of the purchase. This attribute is valuable for compliance analysis and for understanding how different types of requests flow through the process. For example, capital expenditure requests might follow a more stringent and lengthy approval path than standard operational requests. Analyzing the process by Requisition Type can uncover valuable insights for process optimization. Why it matters Allows for segmenting analysis by the business purpose of the request, as different types may have distinct process flows and policies. Where to get This is likely a custom or standard classification field on the Requisition object in Coupa. Examples Capital ExpenseOperational ExpenseIT HardwareProfessional Services
	Supplier Name SupplierName	The name of the supplier or vendor selected for the requisition.
Description This attribute identifies the intended supplier for the goods or services requested. The supplier can be specified by the requester or added later during the sourcing process. Analyzing process metrics by supplier can help evaluate supplier performance and identify if interactions with certain suppliers lead to longer cycle times or other process inefficiencies. It provides important context for procurement strategy and supplier relationship management. Why it matters Allows for analysis of process performance based on the selected supplier, which can inform sourcing strategies and supplier management. Where to get This information is available on the Requisition Line object in Coupa, often as a 'supplier' or 'vendor' field. Examples StaplesDell TechnologiesAccentureCDW
	Urgency Level UrgencyLevel	A classification indicating the urgency of the requisition, such as 'High', 'Medium', or 'Low'.
Description The Urgency Level, often mapped to a priority field, allows requesters to flag requests that require expedited processing. This attribute is essential for the 'Urgent Requisition Processing Time' dashboard. By comparing the cycle times of high-urgency requisitions against standard ones, organizations can assess whether their prioritization mechanisms are effective and if urgent business needs are being met in a timely manner. Why it matters Enables analysis of whether urgent requests are processed faster than standard ones, validating the effectiveness of prioritization policies. Where to get This may be a standard or custom field on the Requisition object in Coupa. Consult Coupa documentation or system configuration. Examples HighMediumLow

Required Recommended Optional

Purchase to Pay - Requisition Activities

These are the key process steps and milestones to capture in your event log for accurate discovery of your Purchase to Pay, Requisition workflow.

6 Recommended 6 Optional

	Activity	Description
	Purchase Order Created	A purchase order (PO) is successfully generated based on the information from the approved requisition. This event is inferred when a PO record is created that references the source requisition ID.
Why it matters This is the primary successful outcome of the requisition process and marks the handoff to the next stage of Purchase-to-Pay. Analyzing the time from 'Requisition Approved' to this event highlights any delays in execution. Where to get Inferred from the creation of a record in the 'purchase_orders' table that contains a reference back to the originating 'requisition_headers' or 'requisition_lines' ID. Capture Use the 'created-at' timestamp of the PO record linked to the requisition ID. Event type inferred
	Requisition Approved	The requisition has successfully passed all required steps in the approval workflow. This is inferred from the overall status of the requisition header changing to 'approved'.
Why it matters This is a critical success milestone, marking the end of the approval cycle. The time to reach this activity is a primary KPI, and it serves as the trigger for downstream procurement actions. Where to get Inferred from a status change on the 'requisition_headers' table when the 'status' field is updated to 'approved'. The timestamp is recorded in the associated audit trail. Capture Identify the timestamp when the requisition's overall status changes to 'approved'. Event type inferred
	Requisition Closed	The requisition is formally closed, signifying that no further action will be taken on it. This can happen after a PO is created and fulfilled, or if the requisition is canceled after approval but before ordering.
Why it matters This activity serves as a definitive end-point for the requisition's lifecycle. It ensures that cases have a clean conclusion, preventing them from appearing as 'active' indefinitely in process analysis. Where to get Inferred from a status change on the 'requisition_headers' table when the 'status' field is updated to 'closed'. The timestamp is recorded in the associated audit trail. Capture Identify the timestamp when the requisition's overall status changes to 'closed'. Event type inferred
	Requisition Created	A new purchase requisition is initiated and saved as a draft by a user. This is the starting point for every requisition case and is typically inferred from the creation timestamp of the requisition record itself.
Why it matters This activity marks the beginning of the requisition lifecycle. Analyzing the time from creation to submission can reveal delays caused by user uncertainty or system complexity. Where to get This event is captured from the 'created-at' timestamp on the 'requisition_headers' table for a given Purchase Requisition ID. Capture Use the creation timestamp of the requisition header record. Event type inferred
	Requisition Rejected	The requisition is definitively rejected during the approval process and will not be converted into a purchase order. This is inferred from the overall status of the requisition header changing to 'rejected'.
Why it matters This activity represents a terminal failure in the process. Analyzing these events is key to improving the 'Requisition Rejection Rate' and identifying root causes like policy violations or budget issues. Where to get Inferred from a status change on the 'requisition_headers' table when the 'status' field is updated to 'rejected'. The timestamp is recorded in the associated audit trail. Capture Identify the timestamp when the requisition's overall status changes to 'rejected'. Event type inferred
	Requisition Submitted	The requester formally submits the completed requisition into the approval workflow. This event is inferred by observing the requisition's status change from 'draft' to 'pending_approval' in the system's audit logs or history tables.
Why it matters Submission triggers the approval process, making it a critical milestone for measuring the 'Average Requisition Approval Cycle Time' KPI. Delays before this point are user-related, while delays after are process-related. Where to get Inferred from a status change on the 'requisition_headers' table, specifically when the 'status' field changes to 'pending_approval'. The timestamp for this change is found in the associated audit trail. Capture Identify the timestamp when the requisition status first changes to 'pending_approval'. Event type inferred
	Approval Step Approved	An individual approver in the workflow gives their approval for the requisition. This is an explicit action logged by the system with a specific timestamp and user information.
Why it matters This activity provides granular insight into the approval process flow. Aggregating these steps helps calculate the 'Average Wait Time per Approval Step' and analyze approver performance. Where to get Captured from an explicit 'approve' action recorded in the 'approvals' table or its audit trail, linked to the specific requisition and approver. Capture Filter for 'approve' events in the approval history for the requisition. Event type explicit
	Approval Step Rejected	An individual approver rejects the requisition at their stage in the workflow, typically sending it back to the requester for amendment. This is an explicit action recorded by Coupa.
Why it matters Rejections at any step create rework and extend cycle times. Analyzing where and why rejections occur is crucial for process improvement and user training. Where to get Captured from an explicit 'reject' action recorded in the 'approvals' table or its audit trail, linked to the specific requisition and approver. Capture Filter for 'reject' events in the approval history for the requisition. Event type explicit
	Approval Step Started	An approval task is assigned to a specific approver or approval group, and the requisition is now awaiting their action. This is inferred when an approval record associated with the requisition is created with a 'pending' status.
Why it matters This marks the start of the waiting time for a specific approval. Measuring the duration between this and the corresponding 'Approval Step Approved/Rejected' helps identify specific bottlenecks in the approval chain. Where to get Inferred from the creation timestamp of a record in the 'approvals' table linked to the requisition, where the approver's action status is 'pending' or equivalent. Capture Use the creation timestamp of an individual's pending approval record in the approval chain. Event type inferred
	Requisition Amended	The requisition is edited by the requester or another authorized user after it has already been submitted. Coupa explicitly logs this as a new version or an audit entry, often resetting some or all of the approval workflow.
Why it matters Tracking amendments is key to understanding process rework and inefficiency. A high volume of amendments can indicate unclear initial requirements or complex purchasing policies, impacting the 'Requisition Amendment Rate' KPI. Where to get This is captured from audit trail tables associated with the 'requisition_headers' table, which log version changes or specific 'edit' actions. Capture Look for explicit 'edit' or 'update' events in the requisition's history log after submission. Event type explicit
	Requisition Sourced	The approved requisition is sent to a sourcing event, like an RFQ or auction, instead of being immediately converted to a purchase order. This event is inferred when the requisition is linked to a sourcing event object.
Why it matters This activity reveals an important alternative path in the procurement process. It separates simple purchases from more complex, strategic sourcing activities, allowing for more nuanced cycle time analysis. Where to get Inferred by detecting a status change to 'sourcing' or by identifying a link being created between the 'requisition_lines' table and a sourcing event table. Capture Check for status change to 'sourcing' or creation of a link to a sourcing event ID. Event type inferred
	Requisition Withdrawn	The original requester cancels the requisition before it receives final approval. This is a user-driven, explicit action that terminates the process for that requisition.
Why it matters Withdrawals can indicate changed business needs, duplicate requests, or users circumventing the process. Tracking this helps understand demand signal volatility and potential process adherence issues. Where to get Inferred from a status change on the 'requisition_headers' table to 'withdrawn' or a similar state, based on an explicit user action logged in the audit trail. Capture Identify the timestamp when the requisition status changes to 'withdrawn'. Event type inferred

Recommended Optional

Extraction Guides

How to get your data from Coupa

Steps

Log into Coupa: Access your Coupa instance with a user account that has permissions to create and schedule reports.
Navigate to the Reporting Module: Go to the 'Setup' tab and find the 'Reporting' section. Select 'Reports' to open the reporting dashboard.
Create a New Custom Report: Click the 'Create' button to start building a new report. Select 'Custom Report' as the type.
Define Report Data Sources: In the report builder, you must select and join multiple data sources to gather all required information. Start with 'Requisition Headers' as the primary source. Then, add the following related objects:
- 'Approvals': To get details on each approval step, including approver, status, and timestamps.
- 'Requisition Lines': To aggregate total amounts and get item-level details.
- 'Purchase Order Headers': To identify when a requisition is converted into a PO.
- 'Users': To pull full names and department details for requesters and approvers.
Configure Report Columns: Drag and drop the necessary fields from the available data sources into the report layout. This is the most critical step, as these columns will be used to generate the event log. Include at least the following:
- From Requisition Headers: Requisition #, Created At, Submitted At, Updated At, Status, Created by (Login ID), Total, Sourced Externally?
- From Users (for Requester): Full Name, Department Name.
- From Approvals: Created At, Updated At, Status, Approver (Login ID).
- From Purchase Order Headers: PO Number, Created At.
Set Report Filters: Apply filters to scope the data extract. A common and effective filter is to use 'Requisition Headers - Created At' and set a dynamic date range, for example, 'Last 90 days'. You may also want to filter for specific company codes if applicable.
Schedule the Report: Navigate to the 'Schedule' tab within the report builder. Define the frequency for the report to run, such as daily or weekly. Set the time for a low-traffic period.
Configure Delivery: Specify the delivery method. For automation, select 'SFTP' and provide the server credentials and target directory. Alternatively, you can send it to an email address. Choose 'CSV' as the file format.
Save and Activate: Save the report and ensure the schedule is activated. The first report will run at the next scheduled time.
Transform the Data: The generated CSV is a flat file, not an event log. You must use an external script (like Python) or an ETL tool to process this file. The script needs to pivot the data, creating a distinct row for each activity (e.g., a row for 'Requisition Created' using the Created At column, another row for each approval step using the 'Approvals' columns, and a row for 'Purchase Order Created' using the PO Created At column).
Generate Final Event Log: The transformation script should output a final CSV file with the required columns: PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, and other recommended attributes. This file is now ready for upload.

Configuration

Primary Data Sources: The report must be built by joining multiple Coupa objects. The key sources are 'Requisition Headers', 'Approvals', 'Requisition Lines', and 'Purchase Order Headers'.
Date Range Filtering: It is critical to apply a date filter to limit the data volume. A rolling window of the last 3-6 months based on 'Requisition Headers - Created At' is a recommended starting point.
Incremental Loads: For ongoing analysis, schedule the report to run daily and extract data from the previous day (e.g., 'Yesterday') to create incremental loads.
Delivery Configuration: Configure delivery to an SFTP server for robust, automated integration with your data pipeline. Ensure the destination is secure and has sufficient storage.
Required Permissions: The user account configuring the report needs administrative or reporting-specific permissions to create, schedule, and access all required data objects (Requisitions, POs, Approvals, Users).

a Sample Query config

This extraction is configured within the Coupa UI and does not use a direct script. The following outlines the objects and fields required to build the report, which is then transformed into an event log.

**Data Sources (Objects to Join):**
1.  `Requisition Headers` (Primary)
2.  `Approvals` (Joined on Requisition Header ID)
3.  `Users` (Joined from `Requisition Headers` for Requester details)
4.  `Users` (Joined from `Approvals` for Approver details)
5.  `Purchase Order Headers` (Joined on Requisition Header ID)

**Report Columns Configuration (Fields to Select):**

*   **For 'Requisition Created' event:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Requisition #` -> Maps to `PurchaseRequisitionId`
    *   Source Field: `Created At` -> Maps to `EventTime`

*   **For 'Requisition Submitted' event:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Submitted At` -> Maps to `EventTime`

*   **For 'Requisition Amended' event:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Updated At` -> Maps to `EventTime` (Logic must be applied to identify updates after submission)

*   **For 'Approval Step Started' event:**
    *   Source Object: `Approvals`
    *   Source Field: `Created At` -> Maps to `EventTime`

*   **For 'Approval Step Approved' / 'Approval Step Rejected' events:**
    *   Source Object: `Approvals`
    *   Source Field: `Updated At` -> Maps to `EventTime`
    *   Source Field: `Status` -> Used to determine `ActivityName` ('Approved' or 'Rejected')

*   **For 'Requisition Withdrawn' / 'Requisition Approved' / 'Requisition Rejected' / 'Requisition Closed' events:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Updated At` -> Maps to `EventTime`
    *   Source Field: `Status` -> Used to determine `ActivityName`

*   **For 'Requisition Sourced' event:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Updated At` -> Maps to `EventTime`
    *   Source Field: `Sourced Externally?` -> Used in logic to identify this event

*   **For 'Purchase Order Created' event:**
    *   Source Object: `Purchase Order Headers`
    *   Source Field: `Created At` -> Maps to `EventTime`

*   **For General Attributes:**
    *   `Requisition Headers | Requisition #` -> `PurchaseRequisitionId`
    *   `Requisition Headers | Status` -> `RequisitionStatus`
    *   `Requisition Headers | Created By (Full Name)` -> `Requester`
    *   `Requisition Headers | Account Department` -> `Department`
    *   `Requisition Headers | Total` -> `TotalAmount`
    *   `Approvals | Approver (Full Name)` -> `Approver`

Steps

Prerequisites: Ensure you have a Python 3 environment installed. Install the necessary libraries, pandas and requests, by running pip install pandas requests in your terminal or command prompt.
Obtain Coupa API Key: Log in to your Coupa instance as an administrator. Navigate to Setup > Company Setup > API Keys. Create a new API key with at least read permissions for the following scopes: core.purchase_order.read, core.requisition.read, and core.user.read.
Configure the Script: Create a new Python file (e.g., extract_coupa_reqs.py). Copy the provided Python script into this file. Replace the placeholder values for COUPA_INSTANCE_URL with your company's Coupa URL (e.g., https://yourcompany.coupahost.com) and API_KEY with the key you obtained in the previous step.
Set Extraction Parameters: In the main section of the script, adjust the START_DATE and END_DATE variables to define the time window for the data extraction. This filters requisitions based on their creation date.
Execute the Script: Run the script from your terminal using the command python extract_coupa_reqs.py. The script will connect to the Coupa API, fetch the data, and display progress updates in the console.
Handle API Pagination: The script includes a function to automatically handle API pagination. It will fetch data in chunks (pages) of 50 records and continue until all requisitions within the specified date range have been retrieved.
Process Requisition Data: For each requisition header fetched, the script generates the 'Requisition Created' and 'Requisition Submitted' events. It then makes additional API calls to retrieve associated approval and purchase order data.
Generate Activity Events: The script processes the approval records to create 'Approval Step Started', 'Approval Step Approved', and 'Approval Step Rejected' events. It also checks the requisition's final status and related data to generate events like 'Requisition Approved', 'Purchase Order Created', and 'Requisition Withdrawn'.
Detect Amendments: The script checks the version attribute of each requisition. If the version is greater than 1, it signifies an amendment. An 'Requisition Amended' event is created using the updated-at timestamp of the newer version.
Assemble the Event Log: All generated events are collected into a structured list. Each event includes the required attributes like PurchaseRequisitionId, ActivityName, EventTime, and recommended attributes like Requester and TotalAmount.
Export to CSV: Once all requisitions have been processed, the script converts the final event list into a pandas DataFrame and saves it as a CSV file named coupa_requisition_event_log.csv in the same directory. This file is formatted for direct upload to ProcessMind.

Configuration

API Key Permissions: The API key used for extraction must have read access to the requisition_headers, requisition_lines, approvals, purchase_orders, and users objects in Coupa. Without these permissions, the script will fail or return incomplete data.
Date Range: The script uses a date range filter based on the requisition creation date (created-at). It is recommended to extract data in manageable chunks, such as 3 to 6 months at a time, to avoid long run times and potential API timeouts. Adjust the START_DATE and END_DATE variables accordingly.
Status Filtering: The provided script fetches all requisitions regardless of their status. For a more focused analysis, you can add a status parameter to the params dictionary in the initial API call to target specific statuses like approved, pending_approval, or ordered.
Pagination Limit: The script is hardcoded to fetch 50 records per API call (limit=50). This is a standard value that works well with the Coupa API. Increasing it may not necessarily improve performance and could increase the risk of timeouts for complex queries.
Performance Considerations: The script makes multiple API calls for each requisition (one for the header, one for approvals, one for POs). Extracting data for thousands of requisitions can be time consuming and may be subject to Coupa's API rate limits. It is best to run this script during off peak business hours.

a Sample Query python

import requests
import pandas as pd
from datetime import datetime, timezone

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Coupa instance URL and API Key
COUPA_INSTANCE_URL = class="hl-string">"https://[your_instance].coupahost.com"
API_KEY = class="hl-string">"[your_api_key]"

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---

def get_coupa_data(endpoint, params={}):
    class="hl-string">"""Fetches paginated data from a Coupa API endpoint."""
    headers = {
        class="hl-string">"Accept": class="hl-string">"application/json",
        class="hl-string">"X-COUPA-API-KEY": API_KEY
    }
    
    all_records = []
    offset = 0
    limit = 50
    
    while True:
        paginated_params = params.copy()
        paginated_params[class="hl-string">'offset'] = offset
        paginated_params[class="hl-string">'limit'] = limit
        
        try:
            response = requests.get(fclass="hl-string">"{COUPA_INSTANCE_URL}{endpoint}", headers=headers, params=paginated_params)
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raises an exception for 4xx/5xx errors
            data = response.json()
            
            if not data:
                break
                
            all_records.extend(data)
            offset += limit
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data from {endpoint}: {e}")
            break
            
    return all_records

def main(start_date, end_date):
    class="hl-string">"""Main function to extract, transform, and save the event log.""" 
    print(class="hl-string">"Starting Coupa Requisition data extraction...")
    
    event_log = []
    current_time_utc = datetime.now(timezone.utc).isoformat()

    class=class="hl-string">"hl-comment"># 1. Fetch Requisition Headers within the date range
    req_params = {
        class="hl-string">"created-at[gt]": start_date,
        class="hl-string">"created-at[lt]": end_date,
        class="hl-string">"fields": class="hl-string">'["id", "created-at", "submitted-at", "updated-at", "version", "status", "total", "requester", "currency", "sourcing-event-id"]'
    }
    requisition_headers = get_coupa_data(class="hl-string">"/api/requisition_headers", req_params)
    print(fclass="hl-string">"Found {len(requisition_headers)} requisitions to process.")

    for i, header in enumerate(requisition_headers):
        print(fclass="hl-string">"Processing requisition {i+1}/{len(requisition_headers)}: ID {header['id']}")
        
        class=class="hl-string">"hl-comment"># Common attributes for all events of this case
        case_id = str(header[class="hl-string">'id'])
        total_amount = header.get(class="hl-string">'total', {}).get(class="hl-string">'total')
        requester_name = fclass="hl-string">"{header.get('requester', {}).get('firstname', '')} {header.get('requester', {}).get('lastname', '')}".strip()
        department_name = header.get(class="hl-string">'requester', {}).get(class="hl-string">'department', {}).get(class="hl-string">'name')

        base_event = {
            class="hl-string">"PurchaseRequisitionId": case_id,
            class="hl-string">"TotalAmount": total_amount,
            class="hl-string">"Requester": requester_name,
            class="hl-string">"Department": department_name,
            class="hl-string">"Approver": None,
            class="hl-string">"SourceSystem": class="hl-string">"Coupa",
            class="hl-string">"LastDataUpdate": current_time_utc
        }

        class=class="hl-string">"hl-comment"># Activity: Requisition Created
        event_log.append({
            **base_event,
            class="hl-string">"ActivityName": class="hl-string">"Requisition Created",
            class="hl-string">"EventTime": header[class="hl-string">'created-at'],
            class="hl-string">"RequisitionStatus": class="hl-string">"draft"
        })

        class=class="hl-string">"hl-comment"># Activity: Requisition Submitted
        if header.get(class="hl-string">'submitted-at'):
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Submitted",
                class="hl-string">"EventTime": header[class="hl-string">'submitted-at'],
                class="hl-string">"RequisitionStatus": class="hl-string">"pending_approval"
            })

        class=class="hl-string">"hl-comment"># Activity: Requisition Amended
        if header.get(class="hl-string">'version') and int(header[class="hl-string">'version']) > 1:
             event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Amended",
                class="hl-string">"EventTime": header[class="hl-string">'updated-at'], class=class="hl-string">"hl-comment"># Timestamp of the new version
                class="hl-string">"RequisitionStatus": header[class="hl-string">'status']
            })

        class=class="hl-string">"hl-comment"># 2. Fetch Approvals for this requisition
        approval_params = {
            class="hl-string">"approvable-id": header[class="hl-string">'id'],
            class="hl-string">"approvable-type": class="hl-string">"RequisitionHeader"
        }
        approvals = get_coupa_data(class="hl-string">"/api/approvals", approval_params)

        for approval in approvals:
            approver = approval.get(class="hl-string">'approver', {}).get(class="hl-string">'fullname')
            approval_status = approval[class="hl-string">'status']

            class=class="hl-string">"hl-comment"># Activity: Approval Step Started
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Approval Step Started",
                class="hl-string">"EventTime": approval[class="hl-string">'created-at'],
                class="hl-string">"RequisitionStatus": class="hl-string">"pending_approval",
                class="hl-string">"Approver": approver
            })

            if approval_status == class="hl-string">'approved':
                class=class="hl-string">"hl-comment"># Activity: Approval Step Approved
                event_log.append({
                    **base_event,
                    class="hl-string">"ActivityName": class="hl-string">"Approval Step Approved",
                    class="hl-string">"EventTime": approval[class="hl-string">'updated-at'],
                    class="hl-string">"RequisitionStatus": class="hl-string">"pending_approval",
                    class="hl-string">"Approver": approver
                })
            elif approval_status == class="hl-string">'rejected':
                class=class="hl-string">"hl-comment"># Activity: Approval Step Rejected
                event_log.append({
                    **base_event,
                    class="hl-string">"ActivityName": class="hl-string">"Approval Step Rejected",
                    class="hl-string">"EventTime": approval[class="hl-string">'updated-at'],
                    class="hl-string">"RequisitionStatus": class="hl-string">"pending_approval",
                    class="hl-string">"Approver": approver
                })
        
        class=class="hl-string">"hl-comment"># 3. Handle final status and related events
        final_status_event_time = header[class="hl-string">'updated-at']
        final_status = header[class="hl-string">'status']

        if final_status == class="hl-string">'approved':
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Approved",
                class="hl-string">"EventTime": final_status_event_time,
                class="hl-string">"RequisitionStatus": final_status
            })
        elif final_status == class="hl-string">'rejected':
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Rejected",
                class="hl-string">"EventTime": final_status_event_time,
                class="hl-string">"RequisitionStatus": final_status
            })
        elif final_status == class="hl-string">'withdrawn':
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Withdrawn",
                class="hl-string">"EventTime": final_status_event_time,
                class="hl-string">"RequisitionStatus": final_status
            })
        elif final_status == class="hl-string">'closed':
             event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Closed",
                class="hl-string">"EventTime": final_status_event_time,
                class="hl-string">"RequisitionStatus": final_status
            })

        class=class="hl-string">"hl-comment"># Activity: Requisition Sourced
        if header.get(class="hl-string">'sourcing-event-id'):
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Sourced",
                class="hl-string">"EventTime": final_status_event_time, class=class="hl-string">"hl-comment"># Assumes status update time reflects sourcing
                class="hl-string">"RequisitionStatus": final_status
            })

        class=class="hl-string">"hl-comment"># 4. Fetch Purchase Orders to detect PO Creation
        po_params = {class="hl-string">"requisition-header-id": header[class="hl-string">'id']}
        purchase_orders = get_coupa_data(class="hl-string">"/api/purchase_orders", po_params)

        for po in purchase_orders:
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Purchase Order Created",
                class="hl-string">"EventTime": po[class="hl-string">'created-at'],
                class="hl-string">"RequisitionStatus": class="hl-string">"ordered" 
            })

    class=class="hl-string">"hl-comment"># 5. Create and save the DataFrame
    if not event_log:
        print(class="hl-string">"No events were generated. The output file will be empty.")
        return

    df = pd.DataFrame(event_log)
    df = df.sort_values(by=[class="hl-string">"PurchaseRequisitionId", class="hl-string">"EventTime"])
    df.to_csv(class="hl-string">"coupa_requisition_event_log.csv", index=False)
    print(class="hl-string">"\nExtraction complete. Event log saved to coupa_requisition_event_log.csv")

if __name__ == class="hl-string">"__main__":
    class=class="hl-string">"hl-comment"># Define the extraction period. Format: YYYY-MM-DDTHH:MM:SSZ
    START_DATE = class="hl-string">"2023-01-01T00:00:00Z"
    END_DATE = class="hl-string">"2023-06-30T23:59:59Z"
    main(START_DATE, END_DATE)

Steps

Log into Coupa: Access your Coupa instance with a user account that has permissions to create and schedule reports.
Navigate to the Reporting Module: Go to the 'Setup' tab and find the 'Reporting' section. Select 'Reports' to open the reporting dashboard.
Create a New Custom Report: Click the 'Create' button to start building a new report. Select 'Custom Report' as the type.
Define Report Data Sources: In the report builder, you must select and join multiple data sources to gather all required information. Start with 'Requisition Headers' as the primary source. Then, add the following related objects:
- 'Approvals': To get details on each approval step, including approver, status, and timestamps.
- 'Requisition Lines': To aggregate total amounts and get item-level details.
- 'Purchase Order Headers': To identify when a requisition is converted into a PO.
- 'Users': To pull full names and department details for requesters and approvers.
Configure Report Columns: Drag and drop the necessary fields from the available data sources into the report layout. This is the most critical step, as these columns will be used to generate the event log. Include at least the following:
- From Requisition Headers: Requisition #, Created At, Submitted At, Updated At, Status, Created by (Login ID), Total, Sourced Externally?
- From Users (for Requester): Full Name, Department Name.
- From Approvals: Created At, Updated At, Status, Approver (Login ID).
- From Purchase Order Headers: PO Number, Created At.
Set Report Filters: Apply filters to scope the data extract. A common and effective filter is to use 'Requisition Headers - Created At' and set a dynamic date range, for example, 'Last 90 days'. You may also want to filter for specific company codes if applicable.
Schedule the Report: Navigate to the 'Schedule' tab within the report builder. Define the frequency for the report to run, such as daily or weekly. Set the time for a low-traffic period.
Configure Delivery: Specify the delivery method. For automation, select 'SFTP' and provide the server credentials and target directory. Alternatively, you can send it to an email address. Choose 'CSV' as the file format.
Save and Activate: Save the report and ensure the schedule is activated. The first report will run at the next scheduled time.
Transform the Data: The generated CSV is a flat file, not an event log. You must use an external script (like Python) or an ETL tool to process this file. The script needs to pivot the data, creating a distinct row for each activity (e.g., a row for 'Requisition Created' using the Created At column, another row for each approval step using the 'Approvals' columns, and a row for 'Purchase Order Created' using the PO Created At column).
Generate Final Event Log: The transformation script should output a final CSV file with the required columns: PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, and other recommended attributes. This file is now ready for upload.

Configuration

Primary Data Sources: The report must be built by joining multiple Coupa objects. The key sources are 'Requisition Headers', 'Approvals', 'Requisition Lines', and 'Purchase Order Headers'.
Date Range Filtering: It is critical to apply a date filter to limit the data volume. A rolling window of the last 3-6 months based on 'Requisition Headers - Created At' is a recommended starting point.
Incremental Loads: For ongoing analysis, schedule the report to run daily and extract data from the previous day (e.g., 'Yesterday') to create incremental loads.
Delivery Configuration: Configure delivery to an SFTP server for robust, automated integration with your data pipeline. Ensure the destination is secure and has sufficient storage.
Required Permissions: The user account configuring the report needs administrative or reporting-specific permissions to create, schedule, and access all required data objects (Requisitions, POs, Approvals, Users).

a Sample Query config

This extraction is configured within the Coupa UI and does not use a direct script. The following outlines the objects and fields required to build the report, which is then transformed into an event log.

**Data Sources (Objects to Join):**
1.  `Requisition Headers` (Primary)
2.  `Approvals` (Joined on Requisition Header ID)
3.  `Users` (Joined from `Requisition Headers` for Requester details)
4.  `Users` (Joined from `Approvals` for Approver details)
5.  `Purchase Order Headers` (Joined on Requisition Header ID)

**Report Columns Configuration (Fields to Select):**

*   **For 'Requisition Created' event:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Requisition #` -> Maps to `PurchaseRequisitionId`
    *   Source Field: `Created At` -> Maps to `EventTime`

*   **For 'Requisition Submitted' event:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Submitted At` -> Maps to `EventTime`

*   **For 'Requisition Amended' event:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Updated At` -> Maps to `EventTime` (Logic must be applied to identify updates after submission)

*   **For 'Approval Step Started' event:**
    *   Source Object: `Approvals`
    *   Source Field: `Created At` -> Maps to `EventTime`

*   **For 'Approval Step Approved' / 'Approval Step Rejected' events:**
    *   Source Object: `Approvals`
    *   Source Field: `Updated At` -> Maps to `EventTime`
    *   Source Field: `Status` -> Used to determine `ActivityName` ('Approved' or 'Rejected')

*   **For 'Requisition Withdrawn' / 'Requisition Approved' / 'Requisition Rejected' / 'Requisition Closed' events:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Updated At` -> Maps to `EventTime`
    *   Source Field: `Status` -> Used to determine `ActivityName`

*   **For 'Requisition Sourced' event:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Updated At` -> Maps to `EventTime`
    *   Source Field: `Sourced Externally?` -> Used in logic to identify this event

*   **For 'Purchase Order Created' event:**
    *   Source Object: `Purchase Order Headers`
    *   Source Field: `Created At` -> Maps to `EventTime`

*   **For General Attributes:**
    *   `Requisition Headers | Requisition #` -> `PurchaseRequisitionId`
    *   `Requisition Headers | Status` -> `RequisitionStatus`
    *   `Requisition Headers | Created By (Full Name)` -> `Requester`
    *   `Requisition Headers | Account Department` -> `Department`
    *   `Requisition Headers | Total` -> `TotalAmount`
    *   `Approvals | Approver (Full Name)` -> `Approver`

Your Purchase to Pay - Requisition Data Template

Your Purchase to Pay - Requisition Data Template

Purchase to Pay - Requisition Attributes

Purchase to Pay - Requisition Activities

Extraction Guides

Coupa Scheduled Reports for Requisition Data Export

Steps

Configuration

a Sample Query config

Python Script Extraction via the Coupa REST API

Steps

Configuration

a Sample Query python

Extraction using a Third-Party iPaaS Connector

Steps

Configuration

a Sample Query config

Ready to Get Started?

Optimize Coupa P2P Requisitions, Reduce Cycle Time Today

Your Purchase to Pay - Requisition Data Template

Your Purchase to Pay - Requisition Data Template

Purchase to Pay - Requisition Attributes

Purchase to Pay - Requisition Activities

Extraction Guides

Coupa Scheduled Reports for Requisition Data Export

Steps

Configuration

a Sample Query config

Python Script Extraction via the Coupa REST API

Steps

Configuration

a Sample Query python

Extraction using a Third-Party iPaaS Connector

Steps

Configuration

a Sample Query config

We value your privacy

Ready to Get Started?

Optimize Coupa P2P Requisitions, Reduce Cycle Time Today