FeaturesSample reportPricingResourcesLog inStart free
← All resources

Scaling an ISO without adding admin staff

By Albert Cuesta Reig, founder of SplitRun · Updated

The short answer

An ISO's admin load does not grow with the number of merchants. It grows with the number of processors, the number of agents, and the number of special arrangements between them, and each of those multiplies the others. Offices that scale without adding admin staff do four things. They keep one written record of every agreement with its start date, they treat each processor's report as a fixed input that is never edited by hand, they run the same checks every month before anyone is paid, and they let agents look up their own numbers instead of asking. Done that way, one person can close month-end for thirty agents in an afternoon.

Every ISO owner has a version of the same story. At five agents, residuals were an evening's work. At fifteen, month-end took the first week of every month. At thirty, someone was hired to do nothing else, and the owner still got the phone calls.

The instinct is to blame the size of the book. It is almost never the book. A thousand merchants on one processor with ten agents on flat splits is an easy month. Three hundred merchants across four processors with twelve agents, three of whom have overrides, two of whom share accounts, and one of whom changed deals in June, is a hard one. Admin load follows complexity, not volume.

This guide covers what actually breaks as an office grows, in the order it usually breaks, and what the offices that stay lean do differently.

Where the time goes

Ask an office that spends a week on residuals what the week consists of, and it is rarely the arithmetic. It is:

TaskWhy it grows
Cleaning processor reportsEvery new processor is a new layout, a new profit column and new quirks. Four processors is four separate procedures.
Matching merchants to agentsNew merchants every month, reassignments, shared accounts, agents who leave. The list is never finished.
Applying the special casesOverrides, tiered splits, a deal that changed mid-year, a deduction that applies to one agent. Each one is a formula someone has to remember.
Answering agentsEvery question that a statement does not answer becomes an email, and every email becomes a lookup.
Fixing last monthA correction discovered after payment has to be traced, explained and reversed, usually by the one person who understands the file.

The first three grow with processors, agents and arrangements. The last two grow with how little the agents can see and how little the system remembers. Both can be designed out.

What breaks at each stage

Around ten agents: the spreadsheet becomes a system

Somewhere near ten agents the workbook stops being one tab. There is a tab per processor, a tab per agent, a lookup table, and a rates block that someone edits in place. It still works, but only for the person who built it. The first sign of trouble is a rate change: the old percentage is overwritten, and from that month on nobody can reproduce what was paid before.

What the lean office does instead: a rates table with start dates, and a rule that nothing is ever overwritten, only added. It costs nothing and it is the single change that makes the next stage survivable. The layout is in Replacing Excel for ISO residuals.

Around thirty agents: month-end becomes a job

By thirty agents there are usually three or four processors, a handful of overrides, and a few shared merchants. Each of those is manageable alone. Together they mean that a merchant's profit can be split three ways across two income types after a deduction, and the only place that logic lives is inside a formula. The office hires someone to run it, and that person's first month is spent learning the file.

This is also where agent questions turn into a real cost. Thirty agents receiving a PDF total will generate a steady stream of "why is mine lower", and each one takes twenty minutes to answer properly.

What the lean office does instead: it separates the inputs from the rules. Processor reports are loaded untouched. Every agreement lives in one place, written down with its effective date, and the calculation reads from that list rather than from formulas. And agents get their own view, so the "why is mine lower" question is answered by the statement before it is asked. Agent commission transparency covers what that view should contain.

Around a hundred agents: the office cannot see itself

Past a certain size the question changes from "are the numbers right" to "what are the numbers telling us". Which agents carry the book, which merchants are fading, which processor actually makes money after its fees. A residual report answers none of these on its own, because it is organised by merchant, not by agent, processor or trend. In books we have looked at with about twenty-five reps each, three reps have produced roughly half the profit, and the owner did not know which three until it was worked out for them.

What the lean office does instead: it keeps every month in one place so trends exist, and it looks at the book by agent, by processor and by concentration as a matter of routine, not as a project. The guides on merchant attrition warning signs and portfolio concentration describe what to look at.

The four habits that keep admin flat

None of these require software, though software makes each of them easier.

1. One written record of every agreement

Agent, income type, percentage, base, override, shared merchants, deductions, and the date each took effect. When a deal changes, a new row is added with a new date and the old row stays. This is the office's memory. Without it, every question about a past month is an archaeology project.

2. Processor reports are inputs, never edited

Each report is loaded as it arrived and kept. Cleaning, summing multi-row merchants, and picking the right month's tab happen in a separate step that can be repeated. The moment someone edits a processor file by hand, that month can no longer be reproduced. How to read a First Data residual report shows how much cleaning one processor can need.

3. The same checks, every month, before anyone is paid

A short list, run the same way each time:

  • The month on every file is the month being closed.
  • The count of merchants is close to last month's, and every merchant with profit has an agent.
  • Total Profit ties back to the processor's own total.
  • Shares on shared merchants sum to 100%.
  • Each agent's total is compared with last month, and any large move has a known reason.
  • Agents paid, plus overrides, plus house, equals what came in.

The checks matter more than the calculation. A wrong number that passes the checks is rare. A wrong number that was never checked is how an office pays a whole team on the wrong month's figures.

4. Agents look up their own numbers

A statement that shows each merchant, what it produced, what the agent earned on it, and last month beside it, removes most of the inbound questions. A portal that shows history removes most of the rest. The office's time then goes to the few questions that are actually about an error, which are the ones worth the time.

Adding an agent without adding work

Onboarding an agent is where admin quietly accumulates, because it is done differently each time. A repeatable version:

  1. Record the agreement in the rates table before the first merchant is boarded: splits by income type, any override and who it is on, any deductions, and the start date.
  2. Decide who they report to, if anyone earns on their production, and record that too.
  3. Assign their merchants by merchant ID as they board, not by name, and mark any shared ones with the share.
  4. Give them their statement or portal access from the first month, so they check their own merchant list while it is short.
  5. Tell them the publish date and keep it.

An agent set up this way costs the office a few minutes a month from then on. An agent set up by memory costs an hour a month forever.

Adding a processor without adding work

A new processor is more work than a new agent, because it is a new report shape. The office needs, once:

  • Where the profit column is, and whether it is per merchant or needs summing across rows.
  • Which income types the processor's files cover, and whether they arrive together or separately.
  • How the processor identifies merchants, so they can be matched to agents.
  • The day of the month its files usually arrive, so month-end can be planned around the last one.

Once that is written down, the processor becomes a routine input. When it is not, every month re-discovers it.

A month-end, before and after

A picture of what the difference looks like in practice, drawn from offices we have worked with. Details are changed and no office is identified.

Before. Three processors, fourteen agents, two overrides, a few shared merchants. Reports arrive between the 5th and the 12th. The office manager spends the 12th to the 16th building the month: paste each report into the workbook, fix the columns that moved, sum the multi-row files, update the merchant list, apply the rates, chase the two agreements that changed. Statements go out on the 18th. The following week brings eight or nine questions, two of which turn out to be real errors, one of which is from the previous month and was never caught. Roughly five working days, plus the questions.

After. The same office, with the agreements recorded once and the reports loaded as inputs. Reports are loaded as they arrive. When the last one lands on the 12th, the calculation runs, the checks are run against last month, and two merchants without an agent are assigned. Statements are published on the 13th, with each merchant and last month's figure on them. The following week brings two questions, both answered from the statement. Roughly half a day.

The office did not get smaller. It got simpler.

Frequently asked questions

How many agents can one person manage residuals for? With agreements recorded in one place, reports loaded untouched and a fixed set of monthly checks, one person can close month-end for thirty or more agents across several processors in a day or less. Without those, the same office can take most of a week and still produce errors.

When should an ISO hire someone to run residuals? Usually later than it thinks. The trigger is often not size but complexity: a third processor, overrides, shared merchants and mid-year rate changes arriving together. Fixing the process, or moving it into software, is usually cheaper than a hire and removes the risk of one person being the only one who understands the file.

What is the biggest cause of admin work in a growing ISO? Special cases that live in someone's head or in a formula: overrides, shared merchants, rates that changed, deductions that apply to one person. Each is small alone. Together, and undocumented, they are where the week goes.

How do I onboard a new agent to residuals? Record their agreement with its start date before their first merchant boards, decide who if anyone earns an override on them, assign merchants by merchant ID, and give them their statement or portal from the first month so they check their own list while it is short.

How do I add a new processor without breaking month-end? Write down, once, where its profit column is, whether merchants span several rows, which income types its files cover, how it identifies merchants and when its files arrive. After that it is a routine input rather than a monthly discovery.

How does SplitRun help an ISO scale? SplitRun holds every agreement with its effective date, loads each processor's report as it arrives and keeps the original, runs the calculation with overrides, shared accounts and deductions applied in order, and gives each agent a statement and a portal with their history. Month-end becomes load, check, publish. See the monthly workflow, manage agents and verifying numbers.

See what your agents would receive each month.

View the sample report