Xero and Airbase integration

What moves between them

The main flow runs from Airbase into Xero. ml-connector reads approved bills, expense reimbursements, and card transactions from Airbase and posts them into Xero as ACCPAY bills or manual journals, each mapped to the matching Xero account and tracking category. Reference data flows the other direction: the Xero chart of accounts, tracking categories, and supplier contacts are pushed into Airbase so spend is coded to valid accounts before it is sent. Payment status is read back from Xero so Airbase reflects when a bill is paid. GL accounts are read-only in Airbase, so ml-connector never overwrites the chart of accounts there.

How ml-connector handles it

ml-connector stores both credential sets encrypted. It refreshes the Xero access token before the 30-minute expiry and sends the Xero-tenant-id header on every call, while presenting the Airbase bearer token against the tenant base URL captured at setup. Because the Airbase webhook signature scheme is confirmed only in the portal, the connector polls Airbase for approved spend on a schedule rather than trusting unverified pushes, and it consumes Xero webhooks as a head start while still polling with If-Modified-Since so nothing is missed. Xero accounts and tracking categories are synced into Airbase first, so every bill line references an account and dimension that already exists. Airbase approval workflows mean a created bill is not yet approved or paid, so the connector keys on status fields and only posts approved records. When a bill carries a PO reference, that number is passed so Airbase can run its three-way match. Each Xero write supplies the record GUID as an upsert anchor to avoid duplicates, since Xero has no idempotency-key header, and 429 responses are retried using the Retry-After header. The Airbase token is long-lived and rotates only by hand, so ml-connector tracks its age and warns before a stale token causes failures. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A 180-person software company runs Xero as its accounting system and adopts Airbase to control corporate cards, vendor bills, and employee reimbursements across two entities. Before the integration, an accountant exported Airbase activity each week and hand-entered bills and card spend into Xero, then chased coding errors when expenses hit the wrong account at month-end. With Xero and Airbase connected, approved bills and card transactions post into Xero automatically, coded against the same chart of accounts and tracking categories finance maintains in Xero, and Xero payment status flows back so Airbase shows what cleared. Month-end close starts with spend already booked and coded, and the weekly re-keying is gone.

What you can do

• •Post approved Airbase bills, reimbursements, and card spend into Xero as bills and journals after each approval.
• •Push the Xero chart of accounts, tracking categories, and supplier contacts into Airbase so spend is coded to valid accounts.
• •Read Xero payment status back into Airbase so it reflects when a bill is paid.
• •Authenticate Airbase with its portal bearer token and tenant base URL, and Xero with OAuth 2.0 refresh tokens and the tenant header.
• •Poll on the schedule you set with Retry-After backoff and a full audit trail on every record.

Questions

Which direction does data move between Xero and Airbase?

The main flow is Airbase into Xero. Approved bills, reimbursements, and card transactions move from Airbase into Xero as bills and journals. Reference data moves the other way, since Xero accounts, tracking categories, and supplier contacts are pushed into Airbase so spend is coded correctly, and Xero payment status is read back into Airbase.

Does the integration rely on Airbase webhooks?

Not as the primary trigger. Airbase supports outbound webhooks, but its signing scheme is confirmed only inside the portal, so ml-connector polls Airbase for approved spend on a schedule for reliability. Xero webhooks are used as a head start, but because they carry only record IDs, the connector still makes follow-up GET calls and runs an If-Modified-Since poll so nothing is missed.

How does ml-connector avoid duplicate bills in Xero?

Xero has no idempotency-key header, so ml-connector supplies the record GUID as an upsert anchor on every write, which makes a repeated post update the same record instead of creating a new one. It also keys on Airbase status fields so only approved bills are posted, and 429 rate-limit responses are retried using the Retry-After value rather than re-sending blindly.