Procure-to-pay and order-to-cash records for finance and operations agents

For event logs from any process, see process mining event logs for agents; the agent and workflow data hub maps the cluster, and SourceX's procurement approval and invoice reconciliation pages describe single steps.

What each P2P and O2C step leaves in the ERP

Each step creates or changes a document, so a usable dataset is an extract of linked document tables plus their change history, not one flat activity list. SAP ECC table names below are familiar examples; S/4HANA consolidates some of them, such as goods movements in MATDOC and accounting lines in the ACDOCA universal journal.

Oracle, NetSuite and Dynamics 365 use other names. Process-mining connectors make a useful mapping checklist: UiPath's P2P documentation, one vendor example of market practice, defines input fields for purchase orders, goods receipts, invoices and payments [7]. Ask which timestamp drives event order, because ERP documents carry a document date, a posting date and an entry time, and posting dates can be backdated.

Exceptions are the cases worth paying for

Clean cases that match and pay on time are cheap to automate with rules; agent value sits where a control stopped the flow and a person decided. A three-way match compares the purchase order, goods receipt and invoice. BPI Challenge 2019, real P2P data from a multinational coatings and paints company, sorts each PO line item into four flows: three-way match with the invoice after goods receipt, three-way match with the invoice before receipt (blocked until goods arrive), two-way match with no receipt, and consignment [1].

Ask for counts per exception type in the sample and state a minimum per type in your request. Exception handling records and approval and rejection records cover labeling these decisions.

Choosing the case notion: item, invoice or customer

Ask for object-centric or relational data, because P2P and O2C are many-to-many: a purchase order has many items, items arrive in partial deliveries, one invoice can cover several orders, and one payment can clear many invoices. A case-centric log forces a single case ID, so shared events get duplicated or dropped.

IEEE 1849-2023 defines XES, the XML format for case-centric event logs and streams, superseding the 2016 version [6]; the ERP-RiskBench authors describe BPI 2019 as an IEEE-XES purchase-order log covering PO creation, goods receipt, invoice receipt and payment clearance [2]. OCEL 2.0 links one event to many objects of different types, qualifies event-to-object and object-to-object relationships, records attribute changes over time, and exchanges logs as SQLite, XML or JSON [5].

Then derive case views yourself: PO items for match exceptions, invoices for AP queues, customers for collections. See object-centric event logs (OCEL 2.0) and ERP transaction and master data for AI training.

Illustrative case: a PO item through a price-variance block

Illustrative example: invented to show structure; it does not describe an available dataset.

{
  "objects": [
    {"id": "po:4500018372", "type": "purchase_order", "attrs": {"company_code": "CC02", "vendor": "vnd_7f3a91", "payment_terms": "2/10 net 30"}},
    {"id": "poi:4500018372-20", "type": "po_item", "attrs": {"qty": 40, "unit_price": 118.00, "currency": "USD", "gr_based_iv": true, "price_tolerance_pct": 5.0}},
    {"id": "gr:5000233190", "type": "goods_receipt", "attrs": {"qty": 40, "movement_type": "101"}},
    {"id": "inv:5105600771", "type": "supplier_invoice", "attrs": {"qty": 40, "unit_price": 126.50, "gross": 5060.00}},
    {"id": "usr:buyer_12", "type": "user", "attrs": {"role": "buyer"}},
    {"id": "usr:ap_clerk_07", "type": "user", "attrs": {"role": "ap_clerk"}}
  ],
  "events": [
    {"id": "e1", "activity": "Create PO item", "time": "2026-03-02T09:14:00Z", "rel": [["poi:4500018372-20", "created"], ["usr:buyer_12", "executed_by"]]},
    {"id": "e2", "activity": "Record goods receipt", "time": "2026-03-09T13:40:00Z", "rel": [["gr:5000233190", "created"], ["poi:4500018372-20", "received_against"]]},
    {"id": "e3", "activity": "Post invoice", "time": "2026-03-10T08:05:00Z", "rel": [["inv:5105600771", "created"], ["poi:4500018372-20", "matched_to"], ["gr:5000233190", "matched_to"]]},
    {"id": "e4", "activity": "Block invoice for payment", "time": "2026-03-10T08:05:00Z", "attrs": {"block_reason": "price_variance", "variance_pct": 7.2}, "rel": [["inv:5105600771", "blocked"]]},
    {"id": "e5", "activity": "Ask vendor to confirm price", "time": "2026-03-11T10:22:00Z", "attrs": {"channel": "email", "note": "[VENDOR_CONTACT] cites price list dated [DATE]"}, "rel": [["usr:ap_clerk_07", "executed_by"]]},
    {"id": "e6", "activity": "Approve price variance", "time": "2026-03-16T15:02:00Z", "attrs": {"reason_code": "contract_price_update"}, "rel": [["usr:buyer_12", "approved_by"], ["poi:4500018372-20", "price_changed"]]},
    {"id": "e7", "activity": "Release payment block", "time": "2026-03-16T15:30:00Z", "rel": [["inv:5105600771", "released"]]},
    {"id": "e8", "activity": "Clear invoice in payment run", "time": "2026-03-27T06:00:00Z", "attrs": {"discount_taken": false}, "rel": [["inv:5105600771", "cleared"]]}
  ],
  "case_outcome": {"paid_amount": 5060.00, "days_blocked": 6, "early_payment_discount_lost": true},
  "privacy": {"vendor": "keyed pseudonym, consistent across tables", "bank_and_tax_ids": "excluded", "free_text": "typed placeholders"}
}

Field names are simplified, not the normative OCEL 2.0 JSON schema. The record keeps the tolerance in force, the qualifiers tying the invoice to the PO item and receipt, and the resolution step with a reason code; the lost discount gives an outcome to score against.

Public P2P and O2C logs: references, not training sets

Public logs suit testing schema mappings and evaluation harnesses but are too narrow to train production agents. BPI Challenge 2019 comes from one company group [1], with values anonymized by a linear translation [2]. RWTH Aachen's P2P log is simulated, though built on genuine SAP transactions and object types [4]. A 2024 Zenodo collection simulates O2C, P2P and two other processes in OCEL 2.0, with mismatches and approval decisions generated by the simulation [3]. Silicon Saxony reports that SAP released SALT, anonymized linked tables from one customer's ERP [8]; its full name, Sales Autocompletion Linked Business Tables, signals a field-autocompletion task rather than order-to-cash tracing.

None carry free-text resolution notes, the emails that released a block, invoice and remittance documents, or the spread of configurations across companies, which is why teams license records from operating businesses.

Training, evaluation and sandbox uses, and their limits

P2P and O2C records serve three jobs, each with its own acceptance test.

• Training next-step and triage policies on the sequence up to a block, the resolution and the elapsed time. Pair events with source documents using documents paired with ERP records: the invoice often explains a variance the log only flags.
• Evaluation by replay. Freeze held-out cases at the exception, give the agent the state and policy, and compare its action with the recorded outcome. Recorded outcomes can be wrong, so screen out cases later reversed or overridden.
• Sandbox seeds. Load master data and open documents into a test ERP. τ-bench scores agents by comparing the final database state with an annotated goal state [9], a pattern that fits P2P tasks; see seed data for enterprise agent sandboxes.

Request the configuration in force for the period (tolerance limits, approval thresholds, payment terms, credit rules), or an agent learns one company's thresholds as facts about invoices.

Vendor, customer and employee data: rights and privacy

These records expose the supplier's vendors, customers and staff, so the supplier must hold rights to share them and each party needs treatment before delivery.

• Trading-partner terms. Prices and credit limits may fall under confidentiality clauses in supply or customer contracts. Pseudonymize partner IDs with keys consistent across tables; if amounts are masked, a scaling that keeps zero at zero, the BPI 2019 approach [2], preserves variance percentages.
• Bank and tax identifiers. Exclude them; a sole proprietor's taxpayer ID can be a Social Security number. Keep a flag that bank details changed.
• People. Approvers, clerks, collectors and vendor contacts need stable role-tagged pseudonyms so approval-chain signals survive.
• Consumer receivables. If the supplier is a financial institution covered by Regulation P, the CFPB's Gramm-Leach-Bliley Act privacy rule, that rule limits a recipient's reuse and redisclosure of consumer nonpublic personal information [10].
• California consumers. The CCPA's definition of deidentified information requires the holding business to contractually obligate recipients to comply, including the no-re-identification commitment [11].

For datasets SourceX sources, rights review checks that the business owns or may share the records and that required consents are in place. Names, emails, phone numbers and account numbers are removed or replaced before delivery, the method is recorded and a sample is checked; no de-identification method is perfect.

Request template for P2P and O2C records

A request should name the process scope, case notion, exception mix and licensed uses so a supplier can check its systems against it.

On delivery, check that every invoice item links to a PO item or is flagged non-PO, that payments clear identifiable invoices, that pseudonyms join across tables, and that totals reconcile per entity and period.

SourceX sources operational datasets, including finance workflows, from US companies on request rather than from stock, so a request does not guarantee a match. Its finance and accounting agent data page covers the wider use case and licensing purchase orders covers one document type; for records spanning the full process, send your P2P or O2C specification.

Request P2P and O2C records from US businesses

Describe the process scope, exception mix, documents and uses you need. SourceX looks for US businesses that hold matching records, checks the data and the supplier's licensing permissions, manages the license, and coordinates delivery and payment; nothing is contracted until a supplier agrees. Specify your workflow dataset.