Sage Intacct and Airbase integration

What moves between them

The main flow runs from Airbase into Sage Intacct. When Airbase approves a bill, purchase order, or payment, ml-connector reads the record via REST and posts it into Intacct's vendor ledger and GL accounts via XML. Vendors created or updated in Airbase sync into Intacct's vendor master. Reimbursements and card transactions approved in Airbase post as GL entries in Intacct. GL accounts and the vendor master in Intacct are the authoritative source, so Airbase reflects those changes. The sync runs on a schedule tied to Airbase's webhook events or on a cadence you control.

How ml-connector handles it

ml-connector maintains two credential sets encrypted: the Airbase Bearer token and the Intacct senderId, senderPassword, companyId, userId, and userPassword. On startup, it obtains an Intacct sessionid and caches it in memory with a 50-minute TTL; on each request, it checks if the session is expired and calls getAPISession again if needed. Airbase bills and vendors are read via REST and mapped to Intacct's GL accounts, vendor, and dimension codes. When a bill is approved in Airbase, ml-connector serializes it into Intacct XML format, applying the vendor mapping and GL allocation, and submits it via POST to the XML gateway. Intacct's HTTP 200 responses must be parsed for inner XML error tags, which indicate application-level failures. Retried operations use Intacct's uniqueid flag in the request control block for server-side deduplication. Vendors and GL accounts are synced bidirectionally: changes in Intacct are read on the next poll and compared against Airbase to detect conflicts or new dimensions. Airbase card transactions and reimbursements are treated as read-only from Airbase's perspective; they post as GL entries but are not written back to Airbase.

A real-world example

A growing mid-market services firm uses Sage Intacct for GL and vendor management and Airbase for spend policy enforcement, corporate card management, and expense reimbursement. Before the integration, the accounting team received approved bills from Airbase and vendors manually entered them into Intacct via XML imports, a process that was error-prone and created a two-day lag. With Sage Intacct and Airbase connected, every approved bill and reimbursement flows into Intacct automatically, allocated to the correct cost center and GL account. Vendors are added to Intacct the moment they are onboarded in Airbase. The firm's GL is always current, and the finance team no longer spends time on manual bill entry.

What you can do

• •Post Airbase-approved bills, purchase orders, and reimbursements into Sage Intacct GL and vendor ledgers with the correct allocations.
• •Sync vendors from Airbase into Intacct's vendor master, and keep Intacct vendor changes reflected in Airbase.
• •Map Airbase cost centers and dimensions to Intacct GL accounts and dimension codes.
• •Cache Intacct sessions for 50 minutes and refresh automatically to avoid authentication overhead on every request.
• •Trigger syncs on Airbase webhook events or on a schedule you control, with retries and a full audit trail on every record.

Questions

Which direction does data move between Sage Intacct and Airbase?

The main flow is Airbase into Sage Intacct. Bills, purchase orders, vendors, and reimbursements approved in Airbase flow into Intacct. Vendors and GL accounts created in Intacct are read on the next poll and compared against Airbase so changes are visible across the platform. Airbase GL accounts are read-only, so ml-connector does not write financial entries back to Airbase.

How does ml-connector handle Sage Intacct's session-based authentication and 50-minute timeout?

ml-connector obtains a sessionid by calling getAPISession with your senderId, senderPassword, companyId, userId, and userPassword. The sessionid is cached in memory with a 50-minute TTL. On each request, ml-connector checks the cache; if expired, it refreshes the session automatically before posting the bill or vendor. This eliminates the need to refresh credentials on every single request.

Does Intacct's XML gateway create any special mapping or retry requirements?

Yes. All Intacct operations are serialized through a single XML gateway endpoint, so requests must be formatted as XML with proper escaping of control characters and entity references. Intacct's HTTP 200 responses may contain application-level errors inside XML error tags, not in the HTTP status, so ml-connector parses the response body for errors. Retried operations use Intacct's uniqueid flag for server-side deduplication, preventing duplicate bill entries on network retries.