Acumatica and Airbase integration

What moves between them

The main flow runs from Airbase into Acumatica. As bills are approved and paid in Airbase, ml-connector reads them and posts them into Acumatica as Bills, with the corresponding Payment records, mapped to the matching Acumatica GL accounts and subaccounts. Vendor records move the same direction so a vendor onboarded in Airbase appears in Acumatica. Reference data flows back: Acumatica vendors and the chart of accounts are sent to Airbase so its spend stays coded to accounts that exist in the ledger. GL accounts are read-only in Airbase, so ml-connector never tries to write the chart of accounts into the spend platform. Cadence is scheduled polling, with Airbase webhooks used as a trigger where they are configured.

How ml-connector handles it

ml-connector stores both credential sets encrypted, obtains an Acumatica OAuth token and refreshes it on a 401, and sends the static Airbase Bearer token on every spend-API call. On the Acumatica side it pins the endpoint version per customer so the version-locked URL resolves, and it wraps every field value in the required value object so writes do not return 400. Because Acumatica has no idempotency key, it checks for an existing Bill by the vendor reference before creating one and uses upsert semantics to avoid duplicate AP entries. It reads Airbase approval and payment status fields, or listens for the approval webhook, so only approved bills post and a draft never lands in the ledger. Vendors and GL accounts are mapped first so every posted line references an account that already exists in Acumatica, and PO reference numbers are carried through so Airbase three-way matching still works. Acumatica returns 429 when the past-minute request count crosses the licensed threshold, so ml-connector backs off with jitter and retries, and it tracks the manually rotated Airbase token so an expired credential surfaces as an alert rather than silent failures. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized technology services firm of about 250 staff runs Acumatica for its general ledger and AP, and rolled out Airbase to give employees corporate cards, expense reimbursement, and a bill-approval workflow. Before the integration, the AP team exported approved bills and card-spend summaries from Airbase each week and re-keyed them into Acumatica, then reconciled vendor lists by hand because a vendor added in one system was missing in the other. With Acumatica and Airbase connected, approved bills and their payments post into Acumatica automatically against the right GL accounts, vendors stay aligned in both directions, and the chart of accounts flows to Airbase so coding is correct at entry. The weekly re-keying step is gone and month-end AP reconciliation starts clean.

What you can do

• •Post approved Airbase bills and their payments into Acumatica AP, coded to the correct GL accounts and subaccounts.
• •Keep vendor master data aligned so a vendor onboarded in Airbase appears in Acumatica.
• •Send the Acumatica chart of accounts to Airbase so every transaction is coded to a real account.
• •Bridge Acumatica OAuth with the long-lived Airbase portal token, refreshing and version-pinning automatically.
• •Gate posting on Airbase approval status, with retries and a full audit trail on every record.

Questions

Which direction does data move between Acumatica and Airbase?

The main flow is Airbase into Acumatica. Approved bills, their payments, and vendor records move from Airbase into Acumatica's AP, while Acumatica vendors and the chart of accounts flow back to Airbase. GL accounts are read-only on the Airbase side, so ml-connector never writes the chart of accounts into the spend platform.

How does the integration bridge the two different auth models?

Acumatica uses OAuth 2.0 through its built-in OpenID Connect server, while Airbase uses a single static Bearer token generated in its portal. ml-connector stores both encrypted, refreshes the Acumatica token on a 401, and sends the Airbase token on every call. Because Airbase has no public token-refresh flow, ml-connector tracks the manually rotated token and raises an alert before it expires.

How are duplicate AP bills avoided when posting into Acumatica?

Acumatica has no native idempotency key, so ml-connector checks for an existing Bill by the vendor reference before creating one and relies on upsert semantics so a re-run updates rather than duplicates. It also gates posting on Airbase approval status, so an unapproved or draft bill never reaches the ledger. Any failed downstream call is retried and can be replayed from the audit trail.