Skip to main content
← All posts

Two Requests Under the Limit Are Still One Big Purchase: Catching Split Purchases in Slack

October 8, 2026 · BuyFlow Team

Your spend policy says anything over $5,000 needs the finance lead. On Monday someone in Slack asks for $4,800 of contractor design work. On Wednesday the same person asks for another $4,600 from the same agency, for "phase two." Each request sails through with one manager approval. Together they're $9,400, nearly twice the line that was supposed to bring finance in.

Nobody has to be acting in bad faith for this to happen. Sometimes it's fraud. More often it's someone who knows the threshold, is in a hurry, and figures two small asks will move faster than one big one. Either way, the control you wrote down didn't run.

This post covers what a split purchase looks like, why a threshold that checks one request at a time can't catch it, and what a Slack-first team can do at request time and in a short weekly review in QuickBooks Online or Xero.

What counts as a split purchase

The Palm Beach County Office of Inspector General put out a two-page advisory on this after its audits found employees splitting purchases to get around policy. Its definition is the one to borrow: a split purchase is "the intentional division of a purchase (splitting) into smaller purchases in order to stay within purchase limits and evade procurement requirements" (PBC OIG Tips and Trends #2025-0002).

The advisory lists what people are usually trying to avoid. Translated from government purchasing to a growing company, it's the same list:

  • A threshold that requires a second or senior approver.
  • A threshold that requires competing quotes.
  • A threshold that requires a purchase order.
  • A single-transaction or monthly card limit.

That's the whole point of a tiered approval policy, so it's also exactly what a split goes around.

Why per-request thresholds miss it

A threshold rule looks at one request and asks one question: is this amount over the line? Each piece of a split purchase answers "no" honestly. The problem only shows up when you look at several requests together: same person, same vendor, a short window, a total over the line.

Card-control vendors have been dealing with this for years. Oversight, which audits purchase-card spend, describes split transactions as breaking a high-dollar purchase into smaller ones to get around single-swipe limits, and says dollar limits and merchant-category restrictions alone "are not enough" to stop it (Oversight). Its example: an employee paid for a party cruise for twenty-two guests in small payments over several months, nearly $16,000 in total.

Amazon Business builds the same idea into its Spend Anomaly Monitoring for Prime Business Enterprise members: when the same user places multiple orders to the same address within 48 hours that exceed spending thresholds, the system flags them as potential split purchases for review (Amazon Business). Note what the rule is. It isn't a smarter threshold. It's a grouping: same buyer, short window, combined amount.

You don't need machine learning to apply that grouping. You need your approvals in one place with requester, vendor, amount, and date on every one. If approvals happen in Slack, that's a structured request record, not an emoji on a message.

The red flags, adapted for Slack requests

The PBC OIG advisory lists five indicators (PBC OIG). Here's how each one shows up in a Slack-first company:

  1. Two or more similar requests from the same vendor, each just under a limit. The $4,800 and $4,600 agency asks above.
  2. Unjustified separation of one project into pieces. The advisory's example is separate contracts for labor and materials on the same project. At a startup it's "setup fee" and "first month" as separate requests, or hardware and installation asked for on different days.
  3. Sequential POs or invoices that each stay under the limit. Same vendor, invoice numbers one after another, each one approved on its own.
  4. One person buying the same thing repeatedly in a short window, adding up to more than their single-purchase or monthly limit.
  5. Several people in one team buying the same thing, together over a limit. Splitting across colleagues is still splitting.

Oversight adds one worth watching on cards: round-number amounts. Real purchases usually carry shipping, tax, or fees, so a run of exactly $1,000 charges is unusual (Oversight).

Fix it at request time first

The cheapest place to catch a split is before anyone approves the second half. A few changes to the Slack request make that realistic:

Ask for the full commitment, not this payment. Add a required field: "Total expected spend with this vendor for this need." A $4,800 phase one of a $9,400 project should be approved as a $9,400 project, at the $9,400 tier, with the payment schedule noted.

Show the approver recent history. When a request comes in, the approver should see other requests from the same person to the same vendor over the last 30 days, with their total. If $4,600 lands next to "$4,800 approved 2 days ago, same vendor," the approver can make the call the policy intended without any accusation in the thread.

Route on the combined amount. If the requester's open and recent requests to that vendor add up past a tier, send the new request to the higher tier. That's the same aggregation Amazon Business applies to orders, applied to requests.

Ask for a link to related requests. "Is this part of an earlier request? Link it." Honest phase-two requests get linked and approved quickly. That also keeps legitimate multi-stage work from being treated as suspicious.

Write the rule down. The PBC OIG's first recommendation is to update purchasing policy to expressly prohibit split purchases, give examples, and spell out consequences, then train people on why the thresholds exist (PBC OIG). One sentence in your spend policy and a pinned message in the requests channel cover most of it.

Then a short weekly review in the books

Request-time checks only see what went through Slack. Card swipes, bills that showed up without a request, and anything approved outside the channel still need a look. Keep it short and regular rather than thorough and rare.

In QuickBooks Online, the Transaction List by Vendor report is the natural starting point. Intuit's help shows how to open it from Reports > Standard reports, set the period, and adjust Columns, Filter, and Group by (QuickBooks help). Set it to the last 7 or 30 days, group by vendor, and look for vendors with several transactions that each sit below a tier but add up past it. Save the customized report so the weekly check takes minutes.

In Xero, the Payable Invoice Detail report can be grouped by contact. Xero's community team points out that you can Group by Contact and include Balance, Gross Tax, and Net columns for per-supplier totals (Xero product ideas, Payable Invoice Detail). Xero Central explains how to set Group by and filters, and how to save the layout as a custom report to reuse (Xero Central).

For each cluster you find, ask one question: is there a single approval in Slack that covers the combined amount? If there is, move on. If there isn't, ask the requester what happened. Most answers are mundane, and that's fine. The PBC OIG's recommendations still end with holding people accountable when splitting was deliberate (PBC OIG).

When splitting means the limit is wrong

Repeated splits aren't always a people problem. Sometimes they're a sign that the threshold is in the wrong place. Oversight gives the example of IT staff who keep splitting equipment purchases, and suggests raising their limit from $1,000 to $1,500 so legitimate buying stops being a hassle (Oversight).

The same applies to Slack approvals. If the same kind of purchase keeps getting split under the same line, look at that line. A threshold that routinely gets worked around is giving you a false sense of control and slowing people down at the same time. Move it, or create a standing approval for that category with a monthly cap, and keep the senior review for spend that actually needs it.

A checklist to adopt this week

  • Add "total expected spend for this need" as a required field on Slack purchase requests.
  • Show approvers the requester's last 30 days of requests to the same vendor, with a running total.
  • Route new requests to a higher tier when same-requester, same-vendor requests in the window add up past it.
  • Add one sentence to your spend policy that prohibits splitting and gives an example.
  • Save a vendor-grouped report in QuickBooks Online or Xero and review the last week every Monday.
  • When the same category keeps getting split, revisit the threshold instead of just policing it.

A threshold that checks requests one at a time only works if requests arrive one need at a time. Capture the whole commitment and show approvers the pattern, and that becomes true.

Sources