ml-connector
Wave AccountingAirbase

Wave Accounting and Airbase integration

Wave Accounting is a cloud accounting ledger for small businesses. Airbase is a spend management platform that handles accounts payable, corporate cards, expense reimbursements, and purchase orders. Connecting the two lets Airbase remain the system of record for spend while Wave Accounting holds the books. Each bill, card transaction, reimbursement, and payment in Airbase posts into Wave as a journal entry against the right accounts, and vendors and chart of accounts stay aligned. ml-connector handles the different APIs on each side and moves the data on a schedule you control.

How Wave Accounting works

Wave Accounting exposes its data through a single GraphQL endpoint at gql.waveapps.com, where reads are queries and writes are mutations. It authenticates with OAuth2 authorization-code tokens that expire in about two hours, with the offline_access scope granting a refresh token, and every call is scoped to a businessId obtained right after authorization. Key entities are customers, invoices, products, chart of accounts, journal entries created by moneyTransactionCreate, and vendors. List queries use offset pagination, and Wave pushes signed webhooks for invoice, payment, customer, transaction, and product events. Wave has no native bill, purchase order, or payment object, and the connected business needs an active Wave Pro subscription for third-party access.

How Airbase works

Airbase, now part of Paylocity Finance, exposes a REST API over HTTPS with JSON bodies. Authentication is a long-lived bearer token generated inside the Airbase portal and passed in the Authorization header, paired with a tenant-specific base URL because the platform is multi-tenant. The API covers bills and AP invoices, purchase orders, vendors, payments, expense reimbursements, corporate card transactions, GL accounts, and subsidiaries. GL accounts are read-only on the Airbase side because the source of truth is the connected accounting system. Airbase supports outbound webhooks managed from the portal, with purchase request approval confirmed as an event, though the signing scheme is not publicly documented and must be verified in the portal.

What moves between them

The main flow runs from Airbase into Wave Accounting. ml-connector reads approved bills, executed payments, corporate card transactions, and expense reimbursements from Airbase and posts each as a journal entry into Wave against the matching chart of accounts. Vendor records sync from Airbase into Wave so spend lands against a known payee. Wave chart of accounts is read and supplied to Airbase as the coding reference, since Airbase treats GL accounts as read-only and sources them from the connected ledger. The cadence is a scheduled poll of Airbase, with Airbase approval webhooks used to trigger a sync sooner where they are enabled. Wave journal entries are the destination, so ml-connector does not write spend instructions back into Airbase.

How ml-connector handles it

ml-connector stores both credential sets encrypted. It sends the Airbase bearer token against the customer tenant base URL on every request, and on the Wave side it completes the OAuth2 authorization-code flow, fetches the businessId first, and refreshes the access token before it expires rather than waiting for a 401. Because Wave has no bill or AP object, an Airbase bill, payment, card transaction, or reimbursement becomes a Wave money transaction with debit and credit lines mapped to the right chart of accounts entries, which are aligned first so every line lands on a valid account. The Wave externalId on each transaction is set to a stable id derived from the Airbase record, so a retry re-posts under the same key instead of duplicating the entry. Airbase approval webhooks can trigger a sync, but because the Airbase signing scheme is not publicly confirmed, the connector verifies it against the portal configuration and otherwise relies on scheduled polling. Airbase uses a portal-generated token with no public refresh flow, so ml-connector tracks the token and surfaces a rotation reminder before it can cause an outage, and it backs off and retries on rate-limit responses from either side.

A real-world example

A thirty-person creative agency runs Wave Accounting for its books because the accounting product is free, and adopts Airbase to control corporate card spend, employee reimbursements, and vendor bills as headcount grows. Before the integration, the finance lead exported card and bill activity from Airbase each week and hand-entered the totals into Wave, then reconciled the bank feed against entries that were often coded inconsistently. With Wave Accounting and Airbase connected, every approved bill, card swipe, and reimbursement posts into Wave automatically as a journal entry coded to the correct account, and vendors stay aligned across both tools. The weekly re-keying disappears and the books stay current without a dedicated bookkeeper.

What you can do

  • Post Airbase bills, payments, card transactions, and reimbursements into Wave Accounting as journal entries.
  • Map each Airbase spend record to the correct Wave chart of accounts entry before it posts.
  • Keep vendors aligned between Airbase and Wave so spend lands against a known payee.
  • Supply Wave chart of accounts to Airbase as the GL coding reference, since Airbase GL accounts are read-only.
  • Bridge the Airbase tenant bearer token and Wave OAuth2 login, with externalId dedup and retries on every record.

Questions

Which direction does data move between Wave Accounting and Airbase?
The main flow is Airbase into Wave Accounting. Bills, payments, card transactions, and reimbursements move from Airbase into Wave as journal entries, and vendors sync the same direction. Wave chart of accounts is read and supplied to Airbase for coding, and ml-connector does not write spend instructions back into Airbase.
Why does Airbase spend become a journal entry in Wave instead of a bill?
Wave Accounting has no native bill, purchase order, or standalone payment object in its GraphQL API. Airbase is the system of record for those spend documents, so ml-connector records the financial result of each Airbase bill, payment, card transaction, or reimbursement in Wave using the moneyTransactionCreate mutation. Each entry carries debit and credit lines mapped to the right chart of accounts.
How does the integration avoid duplicate entries in Wave?
Wave's money transaction mutation accepts an externalId field that acts as a caller-supplied dedup key. ml-connector sets it to a stable identifier derived from the Airbase record, so if a sync retries after a failure it re-posts under the same key rather than creating a second entry. Wave access tokens are also refreshed before they expire to avoid failed runs mid-sync.

Related integrations

Connect Wave Accounting and Airbase

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started