Connect your billing to your ERP

Relex is your merchant-of-record rail, not your accounting system. You keep 100%
of what your clients pay you (flat $99/mo, 0% commission), and Relex hands the
Relex-side context of that money movement to whatever ledger you already run —
Thomson Reuters Elite / 3E, QuickBooks, Xero, or Odoo.

This connection is direct between you (or your ERP) and Relex. Pull the
export yourself with your own session or an API key — there is no AI-agent
surface for it, on purpose: your aggregate billing history is exactly the kind
of private financial data that should never pass through an agent.

Two sources, two purposes — use both

• This export (below) is the case-context layer: which invoice or earning
  belongs to which Relex case (case_id), which Stripe object it maps to
  (external_id). Stripe has no concept of a Relex case — only this export does.
• Stripe's own reports, in your Express Dashboard (open it via
  GET /v1/partners/connect/dashboard-link), are the fee-accurate source:
  Balance Summary and Payout Reconciliation reports include Stripe's processing
  fees and are built for reconciliation. This export's fee_minor is always
  0 — it does not know Stripe's fee on any transaction. For books that must
  tie out to the penny, reconcile against Stripe's native reports; use this
  export to attach a Relex case_id to each line.

The export endpoint

GET /v1/partners/me/billing/export                          (JSON, default)
GET /v1/partners/me/billing/export?format=csv                (CSV)
GET /v1/partners/me/billing/export?since=2026-01-01           (bound the window)
GET /v1/partners/me/billing/export?status=all                 (include drafts/void, not just revenue)

Authenticated as the partner (session or API key). Read-only — it never moves
money. It returns your own Stripe Connect activity, already normalized into
ledger rows.

• since (ISO date) bounds the window. Defaults to the last 366 days.
• status defaults to paid — only rows that reflect actual cash movement
  (paid and refunded). Pass status=all to also see draft/sent/void
  invoices that never moved money; do not import those as revenue.

What you get

Three row kinds, all scoped to your account:

Each row has a stable set of columns:

date, kind, reference, description,
gross_minor, fee_minor, net_minor, currency,
status, case_id, external_id

• Amounts are integer minor units (e.g. pence/cents) in the row's currency.
  Divide by 100 for two-decimal currencies; keep as-is for zero-decimal
  currencies (JPY, etc.). This is the canonical, rounding-safe form.
• fee_minor is always 0 here — this export does not compute Stripe's
  processing fee. Use Stripe's native Balance Summary / Payout Reconciliation
  reports for fee-accurate figures (see above).
• status — filter or check this before treating a row as revenue;
  draft/sent/void invoices carry no cash movement (only visible with
  status=all).
• external_id is the Stripe object id (invoice or payout), so your ERP can
  reconcile against your Stripe dashboard.

Mapping into an ERP

• Elite / 3E, generic: import the CSV as journal lines. Map net_minor
  (÷100) to the amount, date to the posting date, kind to the account
  (revenue vs. bank), and external_id to the reference for reconciliation.
  For the fee side of the entry, pull the matching line from Stripe's Payout
  Reconciliation report rather than this export.
• QuickBooks / Xero: import as sales receipts (invoice rows) and bank
  transactions (payout rows); key deduplication on external_id.

Run it on a schedule from your side, or pull on demand. Because every row carries
a stable external_id, re-importing is safe — your ERP dedupes on it.