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.
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
More Wave Accounting integrations
Other systems that connect to Airbase
Connect Wave Accounting and Airbase
Free to use. Add your credentials, ping your real systems, and see if we fit.
Get started