Microsoft Dynamics GP and Airbase integration

What moves between them

The main flow runs from Airbase into Microsoft Dynamics GP. After a bill, expense reimbursement, or card transaction clears its approval chain in Airbase, ml-connector reads it and writes it into GP as a payables invoice or GL journal entry, mapped to the matching GP vendor and GL accounts. Vendor records and the GP chart of accounts flow the other direction, from GP into Airbase, so Airbase always codes spend to accounts and suppliers that already exist in GP. GP general ledger accounts are read-only in Airbase, so ml-connector treats GP as the system of record and never lets Airbase overwrite the ledger.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Airbase side it sends the portal Bearer token against the tenant base URL on every request. On the GP side it presents a Windows domain account over the SBA REST or SOAP endpoint the customer has exposed through their firewall, and it accepts the full server URL, tenant, and company database name per customer because GP publishes no shared host. Airbase webhooks, such as a purchase request approval, trigger work as soon as it fires, and because GP has no push mechanism, GP is always polled by modified date on a schedule you set, which also backfills any Airbase event the webhook missed. GL accounts and vendors are mapped first so each posted line references a valid GP account. SBA write bodies are wrapped in the required Payload key, the company value is the SQL database name rather than the display name, and posting targets unposted batches because posted GP records are read-only. Because neither API offers an idempotency key, ml-connector reuses a stable GP document number per Airbase record so a retry produces a GP validation error instead of a duplicate, and it backs off when Airbase returns a 429. Every record carries a full audit trail and can be replayed if a GP post fails.

A real-world example

A 250-person engineering services firm runs Microsoft Dynamics GP on a hosted Windows server for its general ledger and payables, and rolled out Airbase to control corporate cards, employee reimbursements, and vendor bills. Before the integration, an accountant exported approved spend from Airbase each week and re-keyed it into GP as payables invoices and journal entries, picking GL codes by hand and reconciling card statements line by line at month-end. With Microsoft Dynamics GP and Airbase connected, each approved bill, reimbursement, and card transaction posts into GP automatically against the right vendor and account, while the GP chart of accounts feeds back into Airbase so coding is consistent at the source. The weekly export is gone and close starts with payables already booked.

What you can do

• •Post approved Airbase bills, expense reimbursements, and card transactions into Microsoft Dynamics GP as payables invoices or GL journal entries.
• •Push the GP vendor master and chart of accounts into Airbase so spend always codes to accounts and suppliers that exist in GP.
• •Bridge the Airbase Bearer token and tenant URL to a GP Windows account reached over the SBA REST or SOAP endpoint behind your firewall.
• •Act on Airbase approval webhooks while polling GP on a schedule, since Dynamics GP has no webhook or change stream.
• •Reuse a stable GP document number per record and back off on Airbase 429 responses, with a full audit trail and replay on every transaction.

Questions

Which direction does data move between Microsoft Dynamics GP and Airbase?

The main flow is Airbase into Microsoft Dynamics GP. Approved bills, expense reimbursements, and card transactions move from Airbase into GP as payables invoices or journal entries, while vendors and GL accounts flow from GP into Airbase to keep coding valid. GP general ledger accounts are read-only in Airbase, so GP stays the system of record and ml-connector never overwrites the ledger from Airbase.

How does ml-connector reach Dynamics GP if it runs on premises with no cloud API?

Microsoft Dynamics GP is customer-managed on a Windows server with no SaaS edition, so the customer exposes its SBA REST or SOAP Web Services endpoint through their firewall, or runs a local agent. ml-connector authenticates with a dedicated Windows domain account mapped to a GP user, and accepts the full server URL, tenant name, and company database name per customer because GP has no shared host. The company value is the SQL database name, not the display name.

How are duplicates and timing handled when neither system has a clean idempotency key?

Airbase bills, POs, and expenses move through approval chains, so ml-connector only posts records that have cleared approval, driven by webhooks where available and by scheduled polling otherwise. Neither API offers an idempotency header, so it reuses a stable GP document number per Airbase record, which makes a retry fail GP validation rather than create a duplicate. It also targets unposted GP batches, since posted records cannot be changed through the API.