Employer of Record Platform Problems: The 7 That Eat Margin and Create Liability

Why does the scope get built as an HR system instead of an engagement model?

Because the screens look like human resources screens. Workers, contracts, documents, payslips, leave. A developer who has built a human resources system recognises all of it and proposes what they know, and the operations team, who describe their pain as admin, agree.

Off the shelf human resources systems model an employee inside one company under one policy set. They have no concept of a client who is not the employer, a margin, a partner entity, or two notice periods that must be reconciled. Building in that shape reproduces the limitation in your own code, which is worse than buying it, because now you own the constraint.

Model the engagement instead. One object links worker, employing entity, client agreement and country rule set, holding the commercial terms and the statutory employment terms separately and comparing them explicitly. Then a client termination request is not a status change. It computes statutory notice, accrued leave payout and any severance formula, produces the resulting funding call to the client, and refuses to confirm an end date that breaches the employment contract. That refusal is the control that keeps specific markets profitable. If a proposal draws a status field moving from active to terminated, it is building you a liability with a nice interface.

What goes wrong migrating worker, contract and partner history?

The history you need is spread across a shared drive of signed contracts, twelve partners' payroll registers in a dozen formats, a spreadsheet of margins, and an invoicing history in an accounting package that knows amounts and not composition. Nothing in that set records which clause version a worker's contract was built from, or how a given month's employer contributions split by country.

The specific trap is migrating workers without their contract terms. A worker record with a start date, a salary and a country looks complete and cannot answer the only question that matters at termination, which is what this specific contract says about notice and severance. Providers discover the gap during their first contested exit, when somebody has to read a PDF to establish an obligation the system should already have known.

Migrate the terms, not just the people. For every live worker, capture contract type, probation status, notice terms, working time provisions, benefit entitlements and the governing entity as structured fields, with the signed document attached as evidence rather than as the source of truth. That is manual reading work and it should appear in the plan as staff hours with a named owner. Then let closed engagements come across as reference records only. And do not migrate historical payroll registers into the live ledger, because a funding ledger seeded with unreconciled history never balances and everyone stops trusting it in the first month.

Why do partner, benefits and client integrations break after launch?

Partner payroll files break constantly and that is normal rather than a failure. A small accounting practice in a market where you have four workers will change a column heading, add a statutory line item after a local budget, or send an extra header row. Trying to standardise partners is a project that never finishes, and the ones who agree will fill your template in wrong.

Benefits brokers break on enrolment timing, since a worker enrolled mid month produces a partial premium that does not match your calculated deduction. Client integrations break on people: an enterprise client changes its single sign on configuration or its human resources system, and nobody tells the vendor that runs their international employment.

Build to absorb the mess. Each partner gets an ingestion profile holding their layout, column meanings, currency and decimal conventions and their local statutory line item names mapped to your internal chart, so the ninth country is configuration rather than a development ticket. Every ingest produces a worker level variance report against the prior cycle, because the dangerous failure is not a broken file, it is a plausible file with one worker's social contribution silently doubled. Document extraction handles the partners who send PDFs and should always land in a review queue rather than straight into the ledger. And build a partner correction as a re run rather than a rebuild, since a correction arriving on day three of month end is a certainty, not an exception.

What happens when notice rules and the funding ledger are missing?

Statutory notice was covered above and it is the larger liability. The second omission is quieter and just as damaging: no funding ledger. You fund payrolls before clients pay you, or you call funds in advance and hold client money against a run that has not happened. Both positions carry risk, both change daily, and a provider that cannot state its position by currency without building a spreadsheet is flying on instruments it does not have.

Generic invoicing tools produce a document. What the business needs is a ledger: per cycle, what was called from the client, what was received, what was settled to each partner, what remains, and at what rate each conversion happened. Foreign exchange spread on a global payroll is a real component of provider economics and it belongs in the system rather than in treasury's workbook.

Cover it by modelling money movement as its own ledger with client funding calls, partner settlements and currency conversion events as entries, reconciled against bank statements. Then generate the client invoice from the ledger rather than assembling it alongside. When a client queries a line six months later, you show the source register, the rate used and the date instead of an explanation. That difference is why one operations team answers in two minutes and another opens nine files.

Should you build custom or configure what you already own?

Stay manual if you are under about 50 workers across three or four countries with a stable partner set. Spreadsheets, a shared drive and a competent finance person will carry that, and a platform at that stage consumes the capital you need for sales and entity setup. We have talked several providers out of building at that size and would do it again.

The buy option barely exists here, and that is the defining feature of the category. Deel, Remote, Velocity Global, Papaya Global and Globalization Partners sell the same service you sell. They are competitors rather than vendors, and licensing a competitor's platform means renting your core operations from the firm trying to win your clients. What you can buy sits at the edges: per country payroll engines, global payroll aggregators, identity verification, background checks and signature. The middle layer that links worker, client agreement, entity and statutory rules is the business, and there is very little to buy.

Build when two or more apply: month end reconciliation consuming more than two days of skilled time, more than eight partner file formats, a client asking for a portal or an interface you had to decline, an absorbed termination cost in a market where statutory notice exceeded the client agreement, or client funds held across cycles without a clear position by currency.

How do hidden costs get into the quote?

Country count at launch is the single largest driver and the most commonly compressed. Each country carries a partner ingestion profile, a contract clause set and a statutory rule set, and none of those are engineering alone: each needs local counsel input and a partner conversation. Ask for pricing per country, in the order of your actual headcount, and refuse a proposal that treats twenty five markets as one line.

Direct payroll calculation is the second and is frequently mistaken for a variant of ingestion. Where you run your own entity and calculate payroll yourself rather than receiving a register from a partner, the work is substantially larger, and it recurs whenever local rates change. Decide market by market whether you are calculating or ingesting, and price them differently.

Third is the contract clause library, which needs counsel approval per market once and review on change. That is a legal budget line, not a development one, and providers who skip it end up with a compliance review that means reading several hundred documents individually. Fourth is client single sign on and human resources integrations, which enterprise clients will ask for. Fifth is the worker mobile experience, worth building once operations are stable and a distraction before that.

What separates a build that works from one that fails here?

The builds that work launch with the eight countries carrying most of the headcount, plus an ingestion framework that makes the ninth a configuration exercise. Providers who insist on every market in release one take roughly twice as long and end up shallow everywhere, which is the worst outcome available because it satisfies nobody and still costs the full amount.

They also build the funding ledger in release one even when the treasury workflow comes later. A provider that can state, on any day, what was called, received, settled and converted at what rate has a different conversation with clients and with its own board than one that cannot. Retrofitting a ledger under an invoicing system that was built first is materially harder than building it underneath from the start.

The failures are visible in the first workshop. Ask a prospective developer to model a termination on the whiteboard. A team that understands the domain separates the client's contractual notice from the worker's statutory notice, asks which entity employs the worker and asks who funds the severance. Ask what they have built around money movement specifically, since multi currency ledgers, funding calls, rate capture at conversion and bank reconciliation are a distinct skill from building human resources screens. Then get ownership in writing before kickoff, the repository, the cloud accounts and the right to hire anyone else, because in a market where every alternative product belongs to a competitor, owning your operating system is the strategy rather than a preference.