ERP for a 50-person company
You are not choosing an ERP. You are choosing how many of your hand-offs become one record.
Count the records two systems both claim to own, and the headcount question answers itself.
Guide · updated 2026-10-17
Most pages on this question are organised around headcount. Under 25 you are a startup, 25 to 200 you are an
SMB, and an ERP becomes necessary somewhere between 10 and 50 employees. That threshold is a guess that has been
copied between pages until it reads like a finding. It is easy to write and impossible to check.
Headcount does not predict system class. A twelve-person importer with three warehouses and two currencies is a
harder project than a sixty-person services firm, and no tier table can explain why. Two cost curves are being
added together and only the gentle one is published. Seat price scales with people. Change cost scales with the
number of processes that must be redesigned and the number of records two systems both claim to own. A cheaper
seat says nothing about the second curve.
Count contested records, not people
A contested record is one piece of data that lives in two or more systems and that a person maintains in both.
Not a record that copies itself across. A record that someone keeps current in two places, and that can therefore
disagree with itself. Write yours down, one line each, naming the two systems and the person who updates both.
Then apply the rule. Zero contested records means there is no ERP question, whatever your headcount. One or two
are solved by a written field-ownership rule or a single integration. Three is a system to maintain deliberately.
Four or more, with finance downstream of all of them, is the thing an ERP actually addresses, and at that point the
count matters more than whether you employ twenty people or eighty.
It also corrects a phrase that is in wide use. A single source of truth is not one application. It is one
owner per record, which is achievable in the systems you already have.
The re-keying log, two weeks
The count tells you where the risk is. A log tells you what it costs. Run it for ten business days, across
everyone who touches a number, not just finance.
- Every time someone types a figure into a second system by hand, they note the pair of systems and the minutes
it took. One line. A shared sheet or a notebook is enough.
- At the end, total the minutes per pair of systems, not per person. The pair is the unit that a project can
remove.
- Under roughly thirty minutes a week for a pair, you have a process rule or an integration, not a platform.
- Over roughly four hours a week inside finance, or any pair where the two numbers routinely disagree, is the
condition an ERP is built for.
Judgment lines, not measurementsThese marks, and every other threshold on this page, are
where the decision changed in the businesses this method was built in. They are not industry averages, no
published study establishes them, and they are stated so you have somewhere to argue from rather than to be
quoted back. The number that decides your case is your own two-week total, which is why the log matters more than
the thresholds do.
The log has a second use that justifies the fortnight on its own. It is the acceptance test. Those same pairs
should read zero after go-live, and a project that cannot name which pairs it removes has no scope, only a budget.
Ask any implementer to state the pairs their proposal eliminates before you compare quotes, and make them show it
on your own transactions in a scripted demo rather than on a slide.
Four options and what breaks each one
These are not tiers and the axis is not price. The axis is how many records the architecture allows to be
contested, and each option is defined by the one condition that forces the next step. Read the right-hand column
first. If the condition in it is already true in your business, the option on that row is not a cheaper choice,
it is a shorter delay, and the delay is paid for twice: once in the stopgap and again in the migration.
Option two is the one nobody names, because nobody sells it. Vendor copy calls it ERP lite or composable and means
a product bundle. As an architecture it is specific: one ledger of record, joined edges. Every balance is owned by
accounting. Stock is owned by one operations application. For each field the two share, one system is named as the
owner in a document a new hire can read, and the sync runs one direction per field so there is never a race. Built
that way it carries a multi-entity services business or a single-warehouse distributor for years, and it has a
definite end, printed above.
The claim that point tools inevitably force an eventual, more expensive consolidation is only true where two tools
both write the same master record. Where ownership is clean, a stack of point tools can run for years without that
bill arriving. The question of whether you have outgrown the software or the
process is the same question seen from the accounting side.
The sequence that survives at this size
Order matters more than scope at 50 people, because you only get one team and it also has a day job.
Step one is the chart of accounts, the item master and the customer master, cleaned where they already sit. The
rule is simple: never migrate a master file you would not be willing to publish internally. It is also the only
free diagnostic, because a business that cleans its masters sometimes finds the pain was the data rather than the
software. The data migration checklist covers what to load and
what has to reconcile.
The order that fails is step four before step three. Inventory is the loudest pain, so it gets
promoted, which puts the hardest data into the new system before anyone has closed a month in it. Then two things
are broken at once and nobody can tell which one caused the other. Hold the line: one clean close first.
The internal capacity price
Readiness lists say appoint an owner. That is not a test, because every project says yes to it. The test is
arithmetic.
One named internal owner, and it is the person who closes the month. Not IT. Not the chief executive as a side
task. That person is freed of at least one full day a week for the duration, and a second named person absorbs that
day's work. If you cannot say whose work stops and who covers it, the project is unfunded no matter what the quote
says, and the quote is the part people check.
There is a corollary that gets written up afterwards as a lesson learned and never turned into a decision
beforehand. When the sponsor and the project manager are the same person, both jobs degrade. The sponsor's job is
to say no to scope. The manager's job is to deliver the scope. One person cannot do both, and at 50 people the
merged role is the default rather than the exception, because there is only one person senior enough to do either.
Treat it as a no-go condition rather than a staffing preference. This is the same mechanism as the
capacity failure, which is a slow drift of missed interim
dates while the status stays green, and the six stages of an
implementation each assume a named owner exists at that stage.
Questions to ask before signing
Licensing mechanics decide what the next three years cost more than the headline seat price does, and every one
of them is cheap to change before signature and expensive to change after. Ask these in this order, and get the
answers in the contract rather than the proposal.
- Does the seat minimum ratchet? That is, can seats be reduced at renewal, or only added. A seasonal business
that cannot go down has bought its peak headcount permanently.
- Is the annual uplift capped in the contract, or only mentioned on the quote.
- Can a bundled module be dropped individually at renewal, or does the bundle only come apart entirely.
- What does a sandbox cost, and what is the API call tier. Integrations consume both.
- Is the partner hourly or fixed-scope, and precisely what triggers a change order.
- Who owns the configuration documentation if you change partners.
The last one is the quiet decider, because the event it covers is not one you control: a partner can lose the
consultant who knows your build, or be replaced for cause, at any point. Whether you own the configuration
documentation decides whether that is a setback of weeks or a restart.
The exit test, and the date
Exit is the part of this decision that gets postponed until it is expensive. For a company this size, whether
you can get your data back out in a readable form is a larger decision than which vendor you pick.
So run the exit test before go-live, and run it with your own staff. Export every master record and every open
transaction out of the new system into files a person can open and read. Then reconcile three of them against the
source by hand. If the vendor has to run the export for you, you have not proved you can leave, you have proved
they can leave on your behalf.
Alongside it, one rule about parallel running. Run the old close process in parallel for exactly one period end.
One close finds the breaks. Two or more means the team has quietly decided the old system is still the truth, and
from that point you are paying for both.
Then the date, which matters more than the duration every page quotes in weeks. Cut over at a period end, in a
quarter that contains neither your busiest operating season nor your year-end audit, and freeze all configuration
changes from two weeks before cutover until the first clean close. For a seasonal business that usually leaves one
viable window a year. Find the window first and size the project to it. That often changes which of the four
options is realistic, which is the opposite of how these decisions are normally made. The
cutover runbook works backwards from the last hour in that window when
you can still change your mind, and that hour is the real test of whether the window was wide enough.
§
The short version: count the contested records, log the re-keying for two weeks, name the day that stops and the
person who covers it, and prove the export. Four pieces of evidence, all of them gathered before anyone demos
anything. A business that holds them usually knows which of the four options it needs, and
ERP or point solution turns the choice between the last two into a
shared-record test you can run on your own data.
Before you shortlistThe readiness check is twenty scored statements about your
data, your close and your inventory. It is free, nothing leaves the browser, and it is willing to tell you the
answer is no.