Pull your EOR cost breakdown for reconciliation

👥

Who this is for — Finance and AP teams who need Remote's EOR costs in their own accounting system: broken down per employee, reconciled against what they pre-funded, and booked to the right accounting dimension.

On US PEO? See Pull your PEO cost breakdown — PEO bills on a different cycle.

What you'll do: pull Remote's invoices for the period, reconcile the estimate you funded up front against the actual costs, attribute each cost to the right person and dimension, and load it into your GL.

How Remote bills your EOR workforce — a two-invoice cycle

Reconciliation only makes sense once you know Remote issues two invoices per month, and the gap between them is the thing you're reconciling:

1. Pre-funding invoice — issued on the first business day of the month. An estimate of the month's cost (gross salary, employer contributions, benefits, known incentives/expenses, 13th/14th salaries). You fund payroll up front from this.
2. Reconciliation invoice — issued around the 3rd–5th business day of the following month. The actuals. Remote compares real cost to what you pre-funded:
   • actual higher → a reconciliation invoice for the difference,
   • actual lower → a reconciliation credit (a credit note you apply to a future invoice),
   • equal → a $0 invoice, nothing to do. One-time and value-added costs (EOR add-ons, mandatory health checks, expense tax gross-ups) also land here.

Analogy: pre-funding is the estimate at the pump; reconciliation is the final receipt — same tank, trued up after the fact.

The breakdown is where finance actually works. GET /v1/billing-documents/{id}/breakdown faithfully itemizes the line items billed on that one document — it doesn't restate payroll cost. You tell the estimate from the true-up by the document's billing_document_type (prefunding_invoice vs reconciliation_invoice); the breakdown lines don't repeat that marker.

Each line carries:

• a type + description — the cost component (e.g. Base Salary, Employer Contribution, EOR service fee, Equity management fee). type is a human-readable label, not a fixed enum — its wording can change, so show it but don't key logic off the exact string; description may be null (it falls back to the label);
• the employment_id it belongs to — the same key the employment endpoints use, your join from what it cost to who it was for. Every line has a non-null employment_id — legal-entity-wide charges (with no employment) are excluded from this breakdown, so it won't necessarily sum to the invoice total;
• two amounts, in integer minor units — invoice_amount/invoice_currency (what you're billed) and source_amount/source_currency (the original), with the fx_rate between them. e.g. invoice_amount: 534163 = £5,341.63.

⚠️ The API does not return estimate-vs-actual variance — you calculate it. variance_from_invoice / variance_from_invoice_amount are an FX/rounding note per line (normally null / 0), not a difference between estimate and actual. To reconcile, diff the pre-funding breakdown against the reconciliation breakdown per employment_id (and type) yourself.

Before you begin

• A company-scoped Remote API token (the billing-documents endpoint requires a company-scoped token via the Authorization Code / OAuth flow).
• You've decided the dimension you book on — cost center, department, or legal entity.
• A read-only, scheduled pull. Run it after the reconciliation invoice issues each month; there are no writes.

The approach

1. List the billing documents for the period — you'll get both the pre-funding and reconciliation invoices (and any reconciliation credit note).
2. Pull each breakdown — tag each line with its document's billing_document_type and keep the employment_id on every line.
3. Join each line's employment_id to the employment record, then to your booking dimension.
4. Reconcile & book — diff reconciliation vs pre-funding per person/dimension to get your estimate-vs-actual variance, apply any reconciliation credits, and post the actual cost to your GL.

Key capabilities

Field names and the exact billing_document_type values live in the API Reference — confirm them there (and let your AI assistant build the calls).

Gotchas & limits

• Never book off the pre-funding invoice alone. It's an estimate; the reconciliation invoice trues it up. Your actual cost is the two together — and each breakdown lists only the lines billed on that document.
• Credits are separate documents. A reconciliation_credit_note is a credit (negative) you apply to a future invoice — handle credit documents, don't just sum invoices.
• One-time / value-added costs land on reconciliation, not pre-funding (add-ons, health checks, expense tax gross-ups) — expect lines with no pre-funding counterpart.
• This breakdown is per-employment. Legal-entity-wide charges (platform/subscription fees with no employment) are excluded, so every line has a non-null employment_id — and the breakdown may not tie to the invoice total. Reconcile those company-level charges from the invoice itself.
• Cost center isn't on the public employment endpoint yet. If you book by cost center, that dimension is in flight — check with your account manager.
• Use the list endpoint, not per-employee polling, and carry the original currency through rather than pre-converting, so your GL ties back to the invoice.

🤖 For AI agents

Point your assistant (or the Remote MCP server) at the API Reference with this plan:

List billing documents for the period (expect a prefunding_invoice and a reconciliation_invoice, plus any reconciliation_credit_note) → pull each document's breakdown (all lines come in one call) → join lines to employments on employment_id → compute estimate-vs-actual variance yourself by diffing the pre-funding vs reconciliation line per employment_id (the API's variance_* fields are FX notes, not this) → convert amounts from minor units → aggregate by the customer's accounting dimension and emit a GL-ready file. Treat credit notes as negative documents. Every breakdown line has a non-null employment_id (legal-entity-wide charges are excluded, so the breakdown may not tie to the invoice total). Treat type as a display label, not a stable key.

Next steps

• Pull your PEO cost breakdown (coming soon) — the US PEO equivalent, which bills differently.
• Pull contractor invoices for AP — the contractor side of the same finance pipeline.
• Pull GL & payroll reports (coming soon) — for Global Payroll customers booking journals.