What 1.6 million purchasing events say about how a company actually buys things

A process manual says: order, receive, invoice, pay. The event log says it takes 77 days, one order item in five needs a payment block lifted and almost every invoice passes through a person's hands.

The log

The BPI Challenge 2019 dataset is one year of purchasing at a large Dutch coatings and paints company: 251,734 purchase-order items and 1,595,923 events across 42 activities. Every event is a step someone (or some batch job) took: create the order item, record the goods receipt, record the invoice, clear it.

Items run through one of four flows. 88% are three-way matched with the invoice allowed to arrive first, as long as it's only cleared once the goods are in. The rest split between invoice-after-receipt, consignment and a handful of two-way matches.

Before measuring anything I dropped 464 items with impossible dates. The earliest event in the raw log is from 1948, in a dataset about 2018.

Buying takes eleven weeks

From creating a purchase-order item to clearing its last invoice, the median is 77 days and one in ten takes more than 128. Two-way matching, with no goods receipt to wait for, closes in about a week.

Where the time goes

The vendor's invoice is dated a median of 1.5 days before the goods arrive. It gets recorded 12 days after them. Some of that is the invoice travelling. With 96% of invoice entry done by hand, some of it is likely a queue, which makes invoice capture the obvious thing to automate. It isn't one spend area's problem either: in each of the four biggest spend areas the median wait is between 8 and 20 days. The month between recording and clearing looks like payment terms doing their job, not delay.

Do the matching rules hold?

Mostly. No invoice-after-receipt item recorded its invoice before the goods arrived. No consignment item carries an invoice at all. Both rules hold without a single exception in the log.

The exception is in the big flow. 654 items (0.4% of the completed ones) had their invoice cleared before any goods receipt was recorded. That's a small share and it may include partial deliveries my simple rule can't see. It's also exactly the list an auditor would ask for first.

Some orders are paperwork after the fact

For 3,528 items (1.7%) the vendor's invoice is dated before the purchase-order item was even created, by a median of 12 days. The buying happened first and the purchase order caught up later. Process teams call these after-the-fact POs. They're one of the first things a purchasing department wants to see.

Where people still do the work

Batch jobs record 27% of goods receipts. For invoices it's a different story: 96% of invoice receipts and 96% of invoice clearings are done by people.

The biggest source of rework points the same way. 22% of items needed a payment block removed, far more than price changes (4.5%) or quantity changes (7.0%). A payment block usually means the invoice didn't match the order or the receipt. So the manual work sits exactly where matching fails.

Half the payment blocks come from one place

Packaging is 43% of all items and needs a block lifted on 26% of them. That makes it 52% of every payment block in the log. Its rate isn't the worst: Latex & Monomers blocks 28% of its items, but it only has 5,004. Packaging's problem is volume. Logistics, at 3%, barely has any. If I were handed this process on a Monday, Packaging's invoice matching is where I'd start.

Blocked items also take longer, though by less than the first comparison suggests. In the main flow they closed at a median of 87 days against 73 for the rest. But Packaging items take 98 days even without a block. Packaging also holds half the blocks, so most of that gap is Packaging being slow. Compared within the same spend area, blocked items close about 4 days later on average and at most 8 in any area with enough items to compare. That's days rather than weeks. It's also still a correlation, not the measured cost of a block.

The whole thing as a map

Here is the log as a process map. It keeps the eight most common activities and every handover between them seen at least 15,000 times. Vendor invoice and goods receipt come in either order (110k one way, 81k the other), which the invoice-first flow allows. And the payment block isn't a side branch. It sits on the road to payment: 49k times, lifting a block leads straight into clearing the invoice.

The long tail

11,938 distinct paths for 251,270 items. The happy path (create, vendor invoice, goods receipt, invoice receipt, clear) covers 20% on its own. The ten most common paths cover 60% and 45 paths cover 80%. The fourth most common path is the happy path plus a payment block (4.5% of items), so blocks sit inside the normal process rather than at its edges. Then come 9,001 paths that happen exactly once. That tail is where a process map turns into spaghetti. It's why variant analysis starts with the top 45 rather than the whole thing.

Where this is weak

• The rules are simplified. Real matching logic has tolerances and partial deliveries, so the 654 early clearings are candidates for review, not confirmed violations.
• "Vendor creates invoice" is a document date. It's the date on the invoice, not when it arrived. A vendor who backdates invoices would show up as an after-the-fact PO.
• No payment terms. The log has no due dates, so it can say when invoices were cleared but not whether they were paid on time.
• One company, one year. These numbers describe this log, not purchasing in general.

Everything here comes from three scripts and one results file in the repo.