Split-PO detection

The job is to find purchase orders that would have required a higher delegation-of-authority stamp as one buy, then hold the orders that have not yet gone to the supplier. A cluster is a hold and a conversation. It is not a fraud finding, and a score is not evidence that someone tried to circumvent the matrix.

This check runs at order, after or as the PO is cut. Approval anomaly flagging watches split-across-days in the requisition queue, before an order exists. A per-header DoA check will pass each child while the work would have sat on a higher row.

POs usually live in source-to-pay suites such as SAP Ariba, Coupa, and Jaggaer. A parked cluster can become an evidence file in a GRC workpaper tool such as AuditBoard.

Cluster open and recently posted POs on four keys, inside a published window. Form a candidate only when those keys line up and the combined amount would have crossed a DoA cut that none of the children crossed alone.

• Requester. Same buying identity, as a stable person ID. A shared buying desk that raises POs for several plants will look like one requester if you key on the desk instead of the requesting manager.
• Cost center. Same charge code. Two sites buying the same SKU are not one buy.
• Category. The same category node the matrix uses. Roofing and crib replenishment can share a facilities buyer and still be unrelated work.
• Supplier. Same vendor master ID. Splitting across two vendors to stay under a stamp is a different pattern. Do not stretch this join to cover it.

Publish the window in days, long enough to catch a buy that was cut to sit under a stamp, short enough that ordinary replenishment does not look like a scheme. Sum the headers with the same tax treatment DoA compliance enforcement uses. Compare that sum to the cut that would have applied to one order for that legal entity, category, and requester. If the sum sits above the cut, hold remaining POs in the cluster that have not been transmitted. Leave transmitted POs on the cluster as evidence.

Two unrelated MRO buys will match on requester, and sometimes on cost center, if you ignore category and supplier. A maintenance manager who orders filters from the catalog vendor on Monday and grease from a second catalog vendor on Thursday is stocking the crib. Require category and supplier on the primary join.

A planned phased delivery will match all four keys. A capital contract that schedules engineering, install, and commissioning as separate POs against named milestones is supposed to look like a sequence. If a parent capex requisition already carried the higher DoA, or the contract schedule is on the PO, suppress the cluster or park it as scheduled phases. Treating the schedule as circumvention is how you stall a line finance already approved as one project.

Do not auto-void POs in a cluster. Voiding is a business action with a named person, a reason the supplier can hear, and a path to recut. Hold, talk, then combine and recut, or release with a reason.

The walkthrough is illustrative, not a measured result.

A plant manager's facilities opex DoA is $25,000. On Monday they cut PO-4418 for $24,600 to Apex Roofing, cost center FAC-04, category facilities-roofing, description "Plant 4 roof membrane, materials." On Wednesday they cut PO-4481 for $23,200 to the same vendor, same cost center, same category, description "Plant 4 roof membrane, labor and install." Each header sits under $25,000 and takes the plant-manager stamp. Combined, $47,800 would have required the regional controller.

The detector parks PO-4481 before transmission and attaches PO-4418 as the sibling. The reviewer opens the work order. The roof replacement is real, budgeted, and scheduled in the shutdown. The manager split materials and labor because the contractor invoices that way, and because each PO fit under their stamp.

The outcome is not a fraud file. The reviewer holds the labor PO, combines the amounts, routes the combined buy to the regional controller named on the matrix, and records that the split was process, not concealment. Auto-voiding PO-4481 would have left the contractor mid-fabrication with no order, and would have taught every plant manager to fight the control.

In the same week the same manager also cuts $1,400 of HVAC filters to the MRO punchout and $2,100 of grease to a second catalog vendor. Same requester, overlapping window, different category nodes, different supplier IDs. Those rows stay out of the roofing cluster. Mixing them in is the unrelated-MRO failure.

Give the controls reviewer the child POs, the four join keys, the window, the combined amount, and the matrix row that would have applied to one order. They choose: combine and reroute, release with a reason (phased delivery, separate work orders, period-end replenishment), return the later PO to the buyer to recut, or open a workpaper.

Do not send the cluster only to the original approver. If the pattern is a split under their stamp, they are not a second pair of eyes. DoA still applies to each child: a person over their limit on one header is an unauthorized click even if you never form a cluster. Sequence detection answers a different question: would these headers together have required a higher named delegate.

If both POs have already gone to the supplier, you still form the cluster. The action is a conversation and, if needed, a workpaper, not a pretend recall.

If the reviewer opens a workpaper, the evidence is the documents, the cluster, and the interview, not the score. SAP Ariba, Coupa, and Jaggaer can hold a PO that has not gone to the supplier. AuditBoard can hold the file. Writing "the model said fraud" into either place is how you get a finding that will not survive a challenge.

Tune the window and the join keys to what the reviewing team can actually work. Run silent against recent POs before you hold live ones, and look at month-end replenishment, capex milestone schedules, and shared buying desks. Switch off a key combination that never produces a real reroute.

PO auto-generation from requisition will mint a clean PO from each approved request. Two requisitions that each passed a stamp become two orders that each look in-policy. Run the cluster on the POs it creates, or you only moved the split from the queue into the ERP.

Low-risk auto-approval is blind to sequences by design. Each child under the published band can stamp with the catalog identity. If the combined amount would have sat above the band, or above that identity's DoA row, hold the later row. Auto-approving each piece because each header is boring is how people walk around the cut.

PO anomaly detection compares a single order to contract price, quantity, and supplier before transmission. A split can be fully on-contract: the right vendor, the right unit price, the right SKU, in two headers instead of one. Keep the two holds separate so a buyer who is on-catalog does not argue price when the problem is the stamp.