Pass a cross-border hire to an employer of record cleanly

Both providers act as an employer of record so that a company can hire in a country where it has no legal entity. Buyers rarely pick between them on features. They pick on whether the specific country a candidate lives in is covered directly by the provider or through a local partner, on how contractor engagement is handled, and on which one their finance team has already contracted with.

That last point is the one that affects recruitment software. Agencies do not choose the EOR. The client does, and different clients choose differently, which is why the integration has to be a category rather than a single connector. Building only for one provider means the second client conversation reverts to a spreadsheet.

We are not going to publish a coverage comparison between providers here. Country lists change, we do not audit them, and a stale table on a CRM marketing page is worse than no table. Ask the provider directly for the country you are hiring into.

A large share of cross-border engagements start as contractor arrangements and later convert to employment through an EOR. Both routes are legitimate. What causes trouble is when the recruitment record does not distinguish them, so nobody can answer later how a given person was engaged, from what date, and whether the arrangement changed.

The planned integration writes the engagement route onto the placement and keeps the conversion date if the route changes. It does not judge whether the route is correct. Classification depends on how the work is directed and performed, which is a fact pattern the CRM cannot see and should not pretend to assess.

The push is one-way for everything that matters: candidate identity, role, location, start date and agreed pay create a draft onboarding for a human to check. The only planned inbound is a status signal so a recruiter can see whether the person has signed and started without needing a seat in the EOR platform.

Payroll runs, tax filings, statutory contributions, benefits selections, time off and expenses will not be mirrored into Surhires. There is no recruitment use for that data, and holding a second copy of it turns a CRM into a system that needs to answer payroll-grade questions about retention and access. We would rather not hold it.

For an agency, the EOR is usually the client's choice and the agency's job is to make the handoff painless and to bill its own fee cleanly. The placement fee stays in Surhires. The employment cost sits with the client and the EOR, and the two should never appear in the same revenue line.

For an in-house team hiring internationally, the EOR is your own vendor and the handoff is the last step of your own process. In that case the useful part of the integration is not the data push but the flag: knowing at requisition stage that a role will need an entity conversation changes the timeline you promise the hiring manager.

Export the placement from Surhires, or work from the placement view, and create the onboarding in Remote.com by hand. Attach the signed offer to the placement record so the document the EOR receives and the document the candidate signed are the same file, with a version history that shows it.

Add a requisition-level field for whether the role needs an employer of record and which provider the client uses. Reporting on that field tells you how much of your desk is cross-border, which is the number that decides whether this integration is worth waiting for or worth raising with us.