Low-risk auto-approval

Low-risk auto-approval posts a request without a person clicking, and only when that request sits inside a published band: in-policy, in-DoA, no exception, no anomaly. Speed is the outcome. Apply it to rows a human would otherwise rubber-stamp, not to rows that still need judgment.

A classifier can confirm the request matches the band you published. It does not invent the cut, and it does not raise the cut because the queue is long. Publish the band. Hidden cuts get gamed.

Do not auto-approve an exception, a DoA mismatch, or a request that approval anomaly flagging already marked. Those stay human even when the amount looks small.

Risk-based approval routing still decides who should look at rows outside the band. Auto-approval is the floor of that design: the set that should not wait for a courtesy click. It is not a way around the matrix.

Buying suites in this class, including Coupa, SAP Ariba, Zip, and ServiceNow, already host approval chains. Configure the band and the stamp on the same record the purchase order will use. A side bot that writes "approved" in chat without posting the buying record is not this control.

The band is a published rule, not a hidden score. A requester and an auditor should be able to read it. All four conditions must be true together. If any one fails, send the row to a person.

Amount. At or below the published auto-approve cut for that legal entity and category. The cut must sit at or below the DoA limit of the posting identity. If that identity is authorized to $1,000 on catalog MRO, the auto-approve cut cannot be $2,500. Use the same total DoA uses (the header, with the tax treatment policy names). Do not evaluate a line in isolation when the header would exceed the cut.

Catalog or preferred supplier. The supplier is the contracted punchout or the current preferred panel for that category and ship-to. A free-text local vendor is not in the band, even under the amount. "Vendor exists in the ERP" is not preferred. Match to a vendor ID, then apply the panel rule.

No exception. No sole-source, no off-panel waiver, no missing-quote justification, no requester override. An exception is a human decision. Auto-approving a waived row treats a one-off as policy.

No anomaly. If the queue has marked an unusual amount, an unusual supplier for the category, or a sequence that looks like a split, hold for a person. The flag is not a reject. It is a reason the row is no longer boring.

Policy pre-check at intake can confirm the form is complete against buying rules. A clean pass is necessary. It is not sufficient. Pre-check does not prove the row is in the auto-approve band, and it does not prove anyone is authorized to post it. Wiring "if pre-check is green, auto-approve" skips the band, the DoA join, and the anomaly check.

Every auto-approved row still needs a posting identity, and that identity still needs a live DoA compliance row for amount, legal entity, and category.

"Under $1,000, no human" without a named identity is an unauthorized posting with a shorter queue. Audit will ask who bound the company. "SYSTEM", a blank approver, or a shared inbox cannot join to the matrix.

Create a dedicated identity (a service account or a named catalog auto-approve principal) that finance put on the matrix for the published band only. That identity is the person who "clicked" for control purposes. Join it the same way you join a human click: stable ID, live row, effective date.

If the row is missing, expired, or the amount, entity, or category sits outside it, do not post. Hold and send the row to the matrix owner. Do not invent a manager from the org chart to keep catalog orders moving. Absence of a human in the queue does not create authority.

Self-approval still fails. The requester cannot be the posting identity on their own request, even when their personal limit would cover the amount. Routing may skip courtesy layers on rows that still need a person. It cannot skip the matrix row.

This walk-through is illustrative, not a measured result.

A plant facilities coordinator orders HVAC filters for Plant 4 from the contracted MRO punchout: $420, preferred supplier, cost center and site filled, no exception, no anomaly flag. Finance published a catalog auto-approve band of $1,000 for MRO in that entity. The posting identity PROC-AUTO has a live DoA row for catalog MRO up to $1,000 in that company code.

All four conditions hold. Stamp with PROC-AUTO. Write the trail: band, amount, supplier ID, no exception, no anomaly, identity, matrix row, timestamp. The coordinator does not wait for a director to rubber-stamp filters. The director's queue stays on the rows that need a person.

Change one fact and the same order must not post.

If the coordinator instead typed a local contractor as a free-text supplier for the same $420, the preferred-supplier condition fails. Pre-check may still pass if the vendor is allowed and the form is complete. Auto-approval must not. Route to a human.

If last week the same coordinator posted $890 of filters on Monday and another $890 on Thursday, each under $1,000, to the same supplier against the same plant, split-PO detection (or the anomaly sequence check) should mark the second row. Combined spend would have sat above the auto-approve cut and, depending on the matrix, above PROC-AUTO's DoA limit. Auto-approving each piece because each header is under $1,000 is how people walk around the cut. Hold the second row for a person. Show the combined amount and the limit a single order would have required.

Do not quote a touchless rate. The useful check is whether every posted stamp can be replayed, and whether splits, exceptions, and flags still reach a person.

The audit record is the control. If a reviewer cannot reconstruct why the row posted without a human click, do not run auto-approval.

For each stamp, persist enough that someone can sit down next quarter and replay it:

• The published band that fired (amount cut, category, entity, catalog or preferred rule).
• The four condition results, with the values at decision time (header amount, supplier ID, exception flag, anomaly flag).
• The posting identity and the matrix row it matched (amount, entity, category, effective date).
• The timestamp and the request ID.

A score without those inputs is not a trail. "Classifier said low risk" is not a trail.

Splits under the cut. Per-request auto-approval is blind to sequences. When combined spend would have required a higher delegate as one order, hold. Do not treat each child as independently boring.

A pre-check pass treated as enough. Completeness is not authorization, and it is not the band. Keep the two reasons separate in the record.

No named identity on the stamp. The PO shows Approved by System, or the approver field is blank. Nobody can join that posting to a DoA row. Fix the identity before you widen the band. Widening a nameless stamp only posts more spend with no one on the matrix.

Start on one catalog category, with a cut the posting identity already covers. Sample stamped rows the way you would sample human approvals. If sampling finds exceptions that posted, the exception flag is not reaching the gate. If sampling finds free-text suppliers, the preferred-supplier join is wrong. Publish the band where requesters can read it.

Success is a shorter rubber-stamp queue, with every auto-posted row carrying a named identity, a live matrix row, and a trail a human can replay. It is not a promise that most requests will never see a person.