Sage 100 and Airbase integration

What moves between them

The main flow runs from Airbase into Sage 100. As bills are approved and card and reimbursement spend settles in Airbase, ml-connector reads them and writes AP invoices into Sage 100 through the local agent, mapped to the matching segmented GL account and vendor. Vendor records move the same direction so a vendor onboarded in Airbase appears in Sage 100 accounts payable. Reference data flows back: Sage 100 vendors and the segmented chart of accounts are sent to Airbase so its spend stays coded to accounts and a vendor 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 on both sides, with Airbase webhooks used as a trigger where they are configured.

How ml-connector handles it

ml-connector stores both credential sets encrypted, sends the static Airbase Bearer token on every spend-API call, and presents the local agent's API key on every call into Sage 100. Because Sage 100 has no cloud API, all AP, GL, and vendor writes go through the on-server Business Object Interface that the local agent wraps; the narrow SOAP surface is not used for accounts payable. The connector 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 AP invoice references a vendor and a segmented account that already exist in Sage 100, and the account key is parsed defensively because segment count and length vary by company. Sage 100 has no idempotency key, so before creating an invoice ml-connector checks the natural VendorNo plus InvoiceNo key, since high-frequency writes can trigger record-locking errors that it backs off and retries. It also 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 specialty distributor of about 180 staff runs Sage 100 on a Windows server for its general ledger, accounts payable, and vendor records, 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 Sage 100, then reconciled vendor lists by hand because a vendor added in one system was missing in the other. With Sage 100 and Airbase connected through the local agent, approved bills post into Sage 100 automatically against the right segmented 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

• •Write approved Airbase bills and card spend into Sage 100 as AP invoices through the local agent, coded to the correct segmented GL accounts.
• •Keep vendor master data aligned so a vendor onboarded in Airbase appears in Sage 100 accounts payable.
• •Send Sage 100 vendors and the segmented chart of accounts to Airbase so every transaction is coded to a real account.
• •Bridge the long-lived Airbase portal token with the local agent's API key, tracking token rotation before it expires.
• •Gate posting on Airbase approval status, with record-lock retries and a full audit trail on every record.

Questions

Which direction does data move between Sage 100 and Airbase?

The main flow is Airbase into Sage 100. Approved bills, card and reimbursement spend, and vendor records move from Airbase into Sage 100 accounts payable, while Sage 100 vendors and the segmented 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 ml-connector reach Sage 100 if it has no cloud API?

Sage 100 is on-premises only and has no native REST or cloud API. Full AP, GL, and vendor access is available only through the Business Object Interface, a COM layer that runs on the Sage 100 server, so a local Windows agent wraps that interface and exposes an HTTPS endpoint the connector calls with an API key. The narrow SOAP surface covers only Customers and Sales Orders, so it is not used for accounts payable.

How are duplicate AP invoices and record locks handled when posting into Sage 100?

Sage 100 has no idempotency key, so ml-connector checks the natural VendorNo plus InvoiceNo key before creating an invoice so a re-run does not duplicate it. Because Sage 100 has no webhooks, it polls the DateLastUpdated and transaction-date fields on a schedule rather than waiting for a push. High-frequency writes can trigger record-locking errors, so failed calls are retried with backoff and can be replayed from the audit trail.