Your Purchase to Pay - Invoice Processing Data Template

The Activity attribute represents a distinct stage or action within the invoice processing workflow. These activities are derived from various system events, such as document creation, status changes, approvals, or user actions recorded in SAP change logs.

Analyzing activities is the core of process mining. It allows for the visualization of process maps, identification of bottlenecks (e.g., long waits after 'Invoice Sent For Approval'), rework loops (e.g., repeated 'Payment Block Set' and 'Payment Block Released' cycles), and compliance deviations. The sequence and frequency of activities reveal the actual, as-is process flow.

It defines the steps in the process map, enabling the visualization of process flows, discovery of bottlenecks, and identification of rework.

This attribute is typically derived from multiple sources, including transaction codes (SY-TCODE), status fields in tables like RBKP (e.g., RBSTAT), and change events from tables CDHDR and CDPOS.

Event Time records the exact moment a business activity was executed and logged in the source system. This timestamp is the chronological backbone of the process, ordering all activities for each invoice into a coherent sequence.

In analysis, Event Time is essential for calculating all duration-based metrics, such as cycle times, waiting times, and processing times between activities. It powers dashboards like the 'Invoice End-to-End Cycle Time' and 'Payment Block Resolution Duration' by providing the data needed to measure the time elapsed between any two points in the process. Accurate timestamps are critical for identifying delays and performance bottlenecks.

This timestamp is essential for ordering events correctly and calculating all performance metrics, such as cycle times and bottleneck durations.

This is typically derived by combining the change date (UDATE) and change time (UTIME) from the change document header table, CDHDR. For specific creation events, it can be the creation date and time from tables like RBKP (ERNAM, ERZET).

The Invoice Number serves as the unique case identifier for the invoice processing journey. Each number corresponds to a single invoice received from a vendor, allowing all related activities, from data capture to final payment, to be tracked as part of one cohesive process instance.

In process mining analysis, this attribute is fundamental for reconstructing the end-to-end lifecycle of every invoice. It enables the connection of disparate events logged in SAP, such as parking, posting, blocking, and clearing, into a chronological sequence. This provides a clear view of how each invoice is handled, how long it takes, and where deviations from the standard process occur.

This is the primary key that links all events related to a single invoice, making it the essential foundation for process analysis and variant exploration.

This is typically the Document Number from the SAP table RBKP, field BELNR, often concatenated with Company Code (BUKRS) and Fiscal Year (GJAHR) for absolute uniqueness.

The Clearing Date marks the final step in the invoice lifecycle: payment. It is the date the open invoice item is cleared by a payment document in the system. This date represents the actual payment execution time.

This attribute is the endpoint for many critical KPIs, including the 'Average Invoice Cycle Time' and 'On-Time Payment Rate'. It is compared against the Payment Due Date to measure payment performance. For cash discount analysis, it is compared against the discount period to see if the payment was made in time to capture the discount.

It marks the completion of the process and is the basis for calculating total cycle time, on-time payment rates, and cash discount realization.

For cleared items, this is the 'Clearing Date' field (AUGDT) from the cleared vendor items table, BSAK.

Invoice Amount represents the total value of the invoice submitted by the vendor. This is a key financial metric for each invoice case.

In process mining, this attribute is essential for value-based analysis. It allows for filtering and segmenting the process based on invoice value, which often correlates with process complexity and approval requirements. For instance, high-value invoices might follow a different, more stringent approval path. It is also used in compliance analysis, for example, checking if high-value invoices bypass required approval steps.

It enables value-based analysis, helping to prioritize high-value invoices and understand how invoice amount impacts process flow and compliance.

This is the 'Gross invoice amount' field (RMWWR) from the invoice document header table, RBKP.

When an invoice has a discrepancy or requires further investigation, a payment block is applied. The Payment Block Reason code specifies why the block was set, for example, due to a quantity variance, price variance, or a manual block.

This attribute is essential for the 'Payment Block Resolution Duration' dashboard. Analyzing the frequency and duration of blocks by reason helps to identify the root causes of payment delays. For instance, if 'Price Discrepancy' is the most common reason for long blocks, it points to a potential issue in master data or the purchase order process that needs to be addressed.

It explains why invoices are delayed, enabling root cause analysis of payment blocks and helping to prioritize process improvement efforts.

The payment block reason can be found at the item level in table RSEG (field SPGRS) or in the accounting document table BSEG (field ZLSPR).

The Payment Due Date is calculated based on the invoice's baseline date and the agreed payment terms. It represents the deadline for making the payment to avoid being late and potentially incurring penalties or damaging vendor relationships.

This attribute is crucial for performance and compliance KPIs like the 'On-Time Payment Rate' and 'Cash Discount Opportunity Loss'. By comparing the actual payment date (Clearing Date) to the Payment Due Date, the analysis can automatically determine if a payment was on time, early, or late. It is a foundational element for the Payment Terms Adherence dashboard.

It serves as the baseline for measuring on-time payment performance and identifying opportunities for capturing early payment discounts.

This date is often calculated. The baseline date for payment (ZFBDT) is in table BSEG. The due date logic also depends on payment terms (BSEG-ZTERM).

The Posting Date is a key date in the accounting process. It determines the fiscal period in which the invoice expense is recognized in the General Ledger. It is typically set by the accounts payable clerk during invoice processing.

In process analysis, the 'Invoice Posted' activity, marked by this date, is a major milestone. The duration from invoice receipt to the Posting Date is a critical component of the overall cycle time. This date is also fundamental for financial reporting and throughput analysis, such as tracking the volume of invoices posted per week or month.

It marks a critical milestone in the process, determines the financial period for the transaction, and is a key component of cycle time calculation.

This is the 'Posting Date' field (BUDAT) from the invoice document header table, RBKP.

The Purchase Order Number links an invoice to the original procurement document. This is fundamental for three-way matching (PO, Goods Receipt, Invoice) and for analyzing the efficiency of the PO-backed invoice process.

This attribute is critical for dashboards like the 'Invoice-PO Matching Discrepancy Rate'. It allows for segmenting the process into PO-invoices versus non-PO invoices, which often have very different processing paths and complexities. Analyzing issues related to specific POs can help diagnose upstream problems in the procurement process.

It connects the invoice to the procurement process, enabling analysis of PO vs. non-PO invoices and identifying matching discrepancies.

This is typically found at the line item level. The 'Purchase Order Number' (EBELN) is in the invoice item table, RSEG. It may need to be aggregated to the header level.

The User Name attribute identifies the specific individual responsible for performing a given activity in the process. This is typically the SAP username logged with the transaction or change event.

This attribute is crucial for performance analysis at the user or team level. It helps answer questions like 'Who are the fastest approvers?' or 'Which users generate the most rework?'. It is used in dashboards to analyze workload distribution, identify training needs, and understand variations in performance across different employees.

It allows for analysis of performance and workload by individual or team, helping to identify top performers, training opportunities, and resource imbalances.

This is the 'Changed By' field (USERNAME) from the change document header table, CDHDR. For creation events, it can be the 'Entered by' field (ERNAM) in tables like RBKP.

The Vendor Number is the master data key that identifies the supplier. This links the invoice transaction to a specific business partner, enabling analysis based on vendor characteristics.

Analyzing the process by Vendor Number can reveal important insights into supplier relationships and performance. For example, it can help identify which vendors consistently submit problematic invoices that lead to payment blocks or discrepancies, or which vendors' invoices are processed most efficiently. This information is valuable for vendor management and strategic sourcing initiatives.

It enables vendor-specific analysis, helping to identify patterns, issues, or efficiencies associated with particular suppliers.

This is the 'Invoicing Party' field (LIFNR) from the invoice document header table, RBKP.

The Company Code is a fundamental organizational unit in SAP Financials, representing an independent legal entity. All financial transactions, including invoices, are posted to a specific company code.

This attribute allows for process analysis to be segmented by legal entity. It is crucial for comparing process performance, compliance, and efficiency across different companies within a corporate group. Dashboards can be filtered by Company Code to provide a company-specific view of invoice processing KPIs.

It enables process comparison and performance benchmarking across different legal entities within an organization.

This is the 'Company Code' field (BUKRS) from the invoice document header table, RBKP.

The Currency attribute specifies the currency in which the invoice amount is denominated, for example, USD, EUR, or JPY.

This attribute provides essential context for the Invoice Amount. It allows for correct interpretation and aggregation of financial data, especially in global organizations dealing with multiple currencies. Analysis can be filtered by currency to compare processing efficiency or issues across different currency zones. For meaningful financial aggregation, amounts may need to be converted to a single reporting currency.

It provides necessary context for any financial amounts, ensuring accurate interpretation and enabling currency-based filtering and analysis.

This is the 'Currency Key' field (WAERS) from the invoice document header table, RBKP.

The Document Type is used to categorize different kinds of business transactions in SAP. For invoice processing, common types include 'RE' for standard invoices or 'KG' for vendor credit memos. The document type controls aspects of the posting, such as the number range used.

In analysis, this attribute allows for filtering the process to specific transaction types. For example, the process for handling a credit memo can be significantly different from that of a standard invoice. Separating these flows using the Document Type provides a more accurate and meaningful process view.

It allows for the separation and analysis of different business transactions, such as invoices versus credit memos, which follow different processes.

This is the 'Document Type' field (BLART) from the invoice document header table, RBKP.

The End Time attribute marks the completion of a specific activity. For many events in SAP, which are logged as single points in time, the End Time will be identical to the Start Time. However, for activities that have a measurable duration, like an approval step that is actively being worked on, it can represent the conclusion of that work.

In process analysis, having a distinct End Time allows for the measurement of activity processing time, separate from the waiting time that precedes it. This helps differentiate how long an activity takes to execute versus how long a case waits for that activity to begin, providing deeper insights into resource efficiency.

It enables the calculation of activity processing time, distinguishing it from the waiting time between activities and improving bottleneck analysis.

This is often the same as the Start Time, derived from CDHDR-UDATE and CDHDR-UTIME. In some cases, it can be derived from workflow logs that explicitly record the start and end of a task.

The General Ledger (G/L) Account is the destination account in the chart of accounts where the financial impact of the invoice is recorded. This is a critical piece of data for financial reporting and cost management.

For process mining, analyzing the G/L account provides a financial dimension to the process flow. The 'General Ledger Account Usage Analysis' dashboard can reveal patterns in spending, identify potential miscoding of invoices, and ensure costs are being allocated to the correct departments or projects. It helps bridge the gap between process execution and financial impact.

It adds a financial dimension to the process, allowing for analysis of cost allocation, spending patterns, and potential invoice miscoding.

This is found at the line item level. The 'G/L Account Number' (HKONT) is in the invoice item table RSEG for PO invoices or BSEG for direct FI invoices.

This is a boolean attribute calculated based on payment terms and the actual payment date. It is set to true if the 'Payment Terms' offered a discount for early payment and the 'Clearing Date' was after the discount period expired. This directly measures financial loss due to process inefficiencies.

This attribute is the foundation of the 'Cash Discount Opportunity Loss' dashboard. It allows for easy quantification of the financial impact of processing delays. By filtering for cases where this flag is true, analysts can investigate the specific process variants and bottlenecks that most frequently lead to missed discounts, providing a strong business case for process improvement.

It directly quantifies the financial loss from process delays, creating a compelling case for optimizing the invoice processing workflow.

This attribute is not in SAP. It is calculated during data transformation by interpreting the 'PaymentTerms' and comparing the 'ClearingDate' to the discount due date.

This is a boolean attribute calculated by comparing the 'Clearing Date' (actual payment date) with the 'Payment Due Date'. If the clearing date is after the due date, the flag is true; otherwise, it is false. This provides a simple, direct measure of on-time payment performance for each invoice.

This attribute simplifies analysis and visualization in dashboards. It allows for easy filtering and aggregation to calculate the 'On-Time Payment Rate' KPI. Users can quickly segment the process to compare the process flows of overdue invoices versus those paid on time, potentially revealing the process patterns that lead to late payments.

It simplifies the analysis of on-time payment performance and allows for easy comparison between on-time and late invoice processes.

This attribute is not in SAP. It is calculated during data transformation using the formula: ClearingDate > PaymentDueDate.

This attribute records the date and time of the most recent data extraction or update. It applies to the entire dataset rather than individual events, providing a clear indication of the data's freshness.

This is a critical metadata attribute for dashboard users and analysts. It helps them understand the time period covered by the analysis and ensures they are making decisions based on current information. It is typically displayed prominently on dashboards to inform users of the data's recency.

It informs users about the freshness of the data, ensuring that analysis and decisions are based on up-to-date information.

This value is generated and injected into the dataset by the data extraction or ETL tool at the time of the data refresh.

Payment Terms define the rules for when an invoice must be paid and what, if any, cash discounts are available for early payment. Examples include 'Net 30 days' or '2% 10, Net 30', meaning a 2% discount if paid in 10 days, otherwise the full amount is due in 30 days.

This attribute is the foundation for the 'Cash Discount Opportunity Loss' dashboard and the 'Cash Discount Capture Rate' KPI. The analysis uses the payment terms in conjunction with the posting and payment dates to determine if a discount was available and if it was successfully taken. It is also key for the Payment Terms Adherence dashboard.

It is essential for analyzing cash discount capture rates and understanding the financial impact of process delays.

This is the 'Terms of Payment Key' field (ZTERM) from the invoice document header table, RBKP.

Processing Time measures the time it takes to execute an activity, from its start to its end. It is calculated as the difference between the End Time and the Start Time of an activity. This is distinct from cycle time, which includes the waiting time between activities.

Analyzing processing time helps to understand the actual effort or touch time for different steps. It can pinpoint activities that are resource-intensive or inefficient. For example, a long 'Invoice Data Captured' processing time could indicate a complex invoice or an inefficient data entry process. This metric is valuable for resource planning and automation initiatives.

It measures the actual work duration for an activity, helping to identify resource-intensive steps and distinguish between active work time and idle waiting time.

This attribute is not in SAP. It is calculated during data transformation using the formula: EndTime - StartTime.

When an approver rejects an invoice, they ideally provide a reason for the rejection. This could be a standardized code or a free-text comment indicating issues like 'Incorrect PO number', 'Duplicate Invoice', or 'Amount incorrect'.

This data is vital for the 'Invoice Rejection Reasons & Trends' dashboard. By analyzing the frequency of different rejection reasons, the business can identify common problems and implement corrective actions. For example, if 'Incorrect PO number' is a frequent reason, it might indicate a need for better communication with vendors or training for data entry staff. This analysis is key to reducing process rework.

It provides the root cause for rejections, enabling targeted process improvements to reduce rework and improve first-time-right rates.

This information is often not stored in a single, standard field. It might be found in workflow container logs, long text fields associated with the document, or specific fields in a custom workflow solution.

The Source System attribute indicates the origin of the event data, for example, a specific SAP ECC instance name. This is particularly important in environments with multiple ERP systems or when data is combined from different sources.

In analysis, this attribute helps differentiate processes and performance across various systems, regions, or business units that might be running on separate instances. It ensures data lineage is clear and allows for system-specific filtering and analysis.

It provides crucial context in multi-system landscapes, allowing for proper data segregation and system-specific performance analysis.

This is typically a static value added during the data extraction process, representing the SAP System ID (TADIR-SRCSYSTEM) or a manually assigned identifier for the specific SAP instance.