One number isn't enough to tell two positions apart
A single recurring debit is easy to spot — the same amount, the same rough interval, obviously one thing. The problem starts the moment a second position joins the account: now there are two recurring debits, sometimes at close amounts, sometimes on overlapping days, and no label on the statement saying which is which.
This page describes how those recurring debits are actually separated — not by matching one number against another, but by reading the full shape of each debit series, so two positions that look similar at a glance stay correctly distinct.
Why amount-only matching fails on a stacked account
A rule that groups debits purely by matching amounts works fine when every position debits a fixed, distinct dollar figure. It breaks down fast in practice, for two reasons: many MCA agreements debit a percentage of that day's card sales rather than a flat amount, so a single position's own debits vary day to day — and two entirely separate positions can happen to debit very close figures, especially if both were sized against similar daily revenue estimates.
Both of these mean amount alone is not a reliable enough signal on its own — the same position can fail to match itself from one day to the next, and two different positions can look like the same one.
There's a third reason amount-only matching fails less obviously but just as often: a manual reviewer scanning a statement tends to anchor on whatever number appears most frequently and mentally treat everything within a rough range of it as "the same debit." That works fine for one position. With two or more, the ranges themselves overlap, and the reviewer's own anchoring bias — a very human shortcut, not a mistake exactly — becomes the thing quietly merging two positions into one.
What this doesn't decide
Doesn't determine which funder a position belongs to
It separates the debit pattern. Matching a pattern to a specific funder's name is a judgment call you make from your own records.
Doesn't calculate a remaining balance or payoff figure
It shows what's been debited and the pattern behind it — the original terms live in each funding agreement, not the bank statement.
Doesn't resolve a genuinely ambiguous debit alone
Where a transaction could plausibly belong to more than one position, it's flagged for your review rather than assigned automatically.
The three signals a real separation needs
Amount range (not a fixed figure — a range, since many positions debit a variable percentage), weekday cadence (which specific days a series actually lands on, since most MCA debits skip weekends but not all skip the same way), and consistency (how reliably the pattern repeats over the full statement period) together give a much sturdier fingerprint for each position than any one signal alone.
What gets read
| Field | Used for |
|---|---|
| Transaction date | Building each series' weekday cadence |
| Debit amount | Establishing each series' typical amount range |
| Description text | A secondary signal when a funder name is legible |
| Running balance | Confirming no transaction is double-counted |
None of these fields is read in isolation from the others — the fingerprint that separates one position from another is built by combining all four, which is precisely why a manual scan that only tracks amount tends to fall short of a process that tracks the full set together.
How it works
Upload the bank statement
The full period you want the debits separated across.
Every transaction is read on its own
Date, amount and description extracted from the statement's own layout.
Candidate series clustered by pattern
Debits sharing an amount range and weekday cadence grouped together.
Ambiguous debits flagged, not guessed
A transaction that could fit more than one series is marked for review.
Exported
Excel, CSV or JSON, with each debit tagged to its separated position.
Two close-amount positions, separated
An account shows debits ranging between $298–$312 on some weekdays and $305–$340 on others — close enough that a manual read had assumed it was one noisy position.
| Series | Pattern |
|---|---|
| Position A | $298–$312, Mon–Fri, started 4 months ago |
| Position B | $305–$340, Mon–Sat, started 6 weeks ago |
The Saturday debit was the tell — Position A never debits on Saturday, and once that day's transactions were isolated, the two overlapping ranges resolved into two clean, distinct series.
Weekly debits mixed with daily ones
Not every MCA position debits daily — some funders debit weekly on a fixed day, at a proportionally larger amount. A weekly debit can look, at a glance, like an unusually large daily debit if the cadence isn't checked carefully. Reading the full interval between occurrences, not just the amount, keeps a weekly series correctly distinct from a daily one even when their total monthly cost is similar.
This matters more than it might seem because a weekly position mistaken for a daily one doesn't just get mislabeled — it distorts the amount range being used to separate everything else, since a large single weekly debit sitting inside a daily group pulls that group's expected range wider than it should be, which can in turn make a genuinely separate daily position harder to distinguish.
Manual vs. automatic
| Manual | Automatic |
|---|---|
| Debits scanned by eye, grouped by rough amount | Every debit read and grouped by full pattern |
| Close-amount positions merged by mistake | Weekday cadence keeps close-amount positions distinct |
| A weekly debit mistaken for a large daily one | Interval between occurrences confirms the actual cadence |
From one position to a genuinely stacked account
Separating a single position from ordinary business expenses is a light task. Separating four or five overlapping positions from each other and from ordinary expenses is a meaningfully harder sorting problem, and exactly where a manual scan is most likely to merge two series that should stay distinct.
Reading every transaction the same way, regardless of how many positions are actually present, keeps the effort per statement flat — what grows is only the number of candidate groupings that need a human confirmation, which accurate pattern-matching keeps small.
Why looking across several months improves the separation
A single month's statement gives a snapshot, but a snapshot can be genuinely ambiguous — thirty days isn't always enough to distinguish a variable-percentage position's natural swing from two separate positions with overlapping ranges. Feeding in three or four months at once gives the separation far more evidence to work from: a pattern that holds steady across sixteen weeks is a much stronger signal than one observed across four.
It also surfaces things a single month hides entirely — a position that started two months back, or one that paid off last month and stopped appearing. Reviewing several months together, rather than one statement at a time, is generally the more reliable way to build an accurate multi-position picture, especially for an account carrying three or more positions at once.
Who uses this
Bookkeepers
Recurring debits separated correctly, without re-scanning a statement by eye each month.
Restructuring advisors
A reliable position count and pattern, even on an account with several stacked advances.
CPAs
Consistent separation across every client's statements, regardless of format.
Business owners
A clear picture of how many recurring debits are actually hitting the account.
Each of these roles shares the same underlying need — a reliable way to answer "how many recurring debits are actually hitting this account, and what does each one cost" — even though what they do with that answer differs. A bookkeeper feeds it into monthly financials, an advisor uses it to frame a negotiation, a CPA folds it into a year-end classification, and a business owner uses it simply to know where they stand before deciding whether to take on anything new.
Why pattern-matching beats a simple amount filter
A tool that only matches on amount will confidently merge two distinct positions the moment their debit ranges overlap, and confidently split one position into two the moment its own variable debits swing wide enough. Reading the full pattern — range, cadence, consistency — together avoids both failure modes, which is why it's the difference between a debt schedule you can actually trust and one that looks plausible until someone checks it.
It's worth being specific about why "looks plausible" is the dangerous middle ground rather than an obvious wrong answer. A schedule built on amount-only matching doesn't come back looking broken — it comes back looking like a normal, complete schedule with a normal-looking position count and normal-looking totals. Nothing about it visibly signals that two positions got merged or one got split. That's exactly what makes the underlying method matter more than whether the output looks reasonable at a glance.
Two failure modes, and why both matter
An imperfect separation fails in one of two directions, and it's worth naming both since they're easy to conflate. Over-merging treats two genuinely distinct positions as one — the schedule ends up with fewer positions than actually exist, each carrying a wider, blurrier amount range than any real position has. Over-splitting does the opposite — one position's ordinary day-to-day amount variation gets read as two separate series, inflating the apparent position count.
Both are costly in different ways. Over-merging understates how much debt service is actually hitting the account and can mask a position that's already paid off sitting alongside one that's still active. Over-splitting overstates the position count and can make a single manageable advance look like two, distorting a refinance conversation or a settlement negotiation built on that count. Weighing amount range, weekday cadence and consistency together, rather than any one signal alone, is specifically what keeps both failure modes rare.
What the exported evidence trail looks like
Every separated debit carries a reference back to the exact statement and transaction line it came from — not just a grouping label. That matters the moment the separation needs to be defended to someone else: a lender evaluating a refinance, an advisor building a settlement case, or an accountant reconciling debt service against the general ledger all want to see where a number actually came from, not just trust the final total.
The export includes each position's full debit history — date, amount, and the source line — alongside a summary total, so the underlying evidence and the rolled-up figure travel together rather than the total being handed over on its own with no way to check it.
Harder cases this is built to handle
A position that renews immediately after payoff
A new advance from the same funder, on similar terms, right after the last one clears — read as a new series with its own start date, not a continuation of the old one.
A short gap in an otherwise steady series
A skipped debit or two — a holiday, a low-balance day the funder didn't attempt — doesn't break an otherwise consistent series apart on its own.
Two positions from the same funder
Same funder, two separate agreements, running concurrently — separated by amount range and cadence the same as two positions from different funders would be.
A position debited through a different processor
Some funders route the daily debit through a card processor rather than a direct ACH pull, changing the description text but not the underlying pattern the separation actually relies on.
Get started with your first statement
Upload one bank statement to see how the recurring debits get separated — no signup required to try it. See the full overview of merchant cash advance reconciliation for how this fits into the rest of the process.
Security and privacy
Uploads are encrypted with TLS from end to end.
Processing runs on infrastructure with SOC 2-aligned controls.
Original documents are deleted shortly after processing.
Nothing you upload is ever used to train AI models.
Given that a bank statement discloses a business's complete financial picture, not just its MCA-related activity, these protections apply to every field on the statement, not only the transactions relevant to a specific separation task.