Which direction does data move between SAP S/4HANA and Airbase?

Master data moves from SAP into Airbase, including vendors, GL accounts, and cost centers, so Airbase codes spend against real SAP dimensions. Approved transactions move the other way: bills post into SAP as supplier invoices, and reimbursements and card spend post as journal entries. Card transactions and GL accounts are read-only in Airbase, so ml-connector does not write them back from SAP.

Does SAP need anything set up before the connection works?

Yes. An SAP administrator must activate a Communication Arrangement for each OData service, such as the Business Partner and Supplier Invoice scenarios, which then supplies the OAuth 2.0 client ID, secret, and token URL. Without an active arrangement the service returns 404, so this is a prerequisite for any read or write.

How does the integration handle SAP write requirements and the lack of webhooks?

Every SAP write needs an X-CSRF-Token, so ml-connector fetches it with a GET, replays the mutating request with the token, and re-fetches on a 403. Because SAP has no native push webhooks, it polls OData on a schedule using a LastChangeDateTime filter and follows the nextLink for paging rather than waiting for a push.

SAP S/4HANAAirbase

SAP S/4HANA and Airbase integration

SAP S/4HANA is the system of record for vendors, the chart of accounts, cost centers, and posted supplier invoices. Airbase is the spend layer where bills, expenses, purchase orders, and card transactions are captured and approved. Connecting the two keeps Airbase coding against real SAP master data and gets approved spend back into SAP without re-keying. ml-connector pushes SAP vendors, GL accounts, and cost centers into Airbase, then reads approved Airbase transactions and posts them into SAP as supplier invoices and journal entries. It manages the OData and REST differences on each side and moves data on a schedule you control.

How SAP S/4HANA works

SAP S/4HANA Cloud exposes finance and procurement data through OData services on a tenant-specific URL, for example A_BusinessPartner and A_Supplier for vendors, A_SupplierInvoice for AP bills, A_PurchaseOrder for purchase orders, A_GLAccountInChartOfAccounts for the chart of accounts, and A_CostCenter for accounting dimensions. Access requires an SAP administrator to activate a Communication Arrangement, which then provides OAuth 2.0 client credentials and a token endpoint; Basic auth with a Communication User is a fallback. All writes need an X-CSRF-Token fetched with a GET first, and OData V2 must be asked for JSON explicitly. SAP has no native push webhooks for external URLs, so records are read by polling with a LastChangeDateTime filter.

How Airbase works

Airbase, now Paylocity Finance, exposes its spend data through a REST API over HTTPS that returns JSON and is secured with a long-lived bearer token generated inside the Airbase portal. The base URL is tenant-specific, so it is captured per customer alongside the token. Bills, purchase orders, and vendors are readable and writable; payments allow triggering runs; expense reimbursements are readable and writable; card transactions and synced GL accounts are read-only because the ERP is their source of truth. Airbase supports outbound webhooks, such as purchase_request_approved, though the signature scheme is confirmed only inside the portal. Bills, POs, and expenses move through approval chains, so a created record is not yet approved or paid.

What moves between them

Master data flows from SAP S/4HANA into Airbase: vendors derived from Business Partners, the chart of accounts, and cost centers, so every Airbase transaction is coded against dimensions that exist in SAP. Transactional spend flows the other way: approved Airbase bills become SAP supplier invoices, and approved reimbursements and card transactions post into SAP as journal entries against the mapped GL accounts and cost centers. Card transactions and GL accounts are read-only in Airbase, so ml-connector never writes them back from SAP. Reference data is refreshed on a schedule and spend is posted as it clears approval, with the cadence set per flow.

How ml-connector handles it

ml-connector stores both credential sets encrypted. For SAP it requests an OAuth 2.0 client-credentials token against the tenant token endpoint, caches it until just before its roughly 12-hour expiry, and sends it as a bearer token; for Airbase it sends the portal-generated bearer token on every REST call. Before any SAP write it performs the mandatory X-CSRF-Token fetch and replays the request with the returned token and cookies, re-fetching on a 403. SAP vendors, GL accounts, and cost centers are mapped first so each posted Airbase bill or expense lands on a valid SAP supplier, account, and cost center, and a bill carries its PO reference so Airbase can three-way match on its side. Because SAP has no native webhooks, ml-connector polls OData with a LastChangeDateTime filter and follows the nextLink for paging; on the Airbase side it can act on webhooks such as purchase_request_approved while a scheduled poll backfills anything missed. SAP returns HTTP 429 with Retry-After under load, so requests back off and retry, and SAP rejects duplicate supplier invoices by vendor, reference, and fiscal year, which guards against double posting. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized software company of around 300 employees runs SAP S/4HANA Cloud for finance and procurement and uses Airbase for corporate cards, employee reimbursements, and vendor bill payments. Before the integration, the accounting team exported approved bills and card spend from Airbase each week and keyed them into SAP as supplier invoices and journal entries, picking GL accounts and cost centers by hand and frequently catching coding mistakes at month-end. With SAP S/4HANA and Airbase connected, the SAP chart of accounts, cost centers, and vendor list are pushed into Airbase so spend is coded correctly at capture, and each approved transaction posts back into SAP on schedule. Close starts with AP already in the ledger and the manual re-entry step is gone.

What you can do

Push SAP S/4HANA vendors, GL accounts, and cost centers into Airbase so spend is coded against valid dimensions.
Post approved Airbase bills into SAP as supplier invoices and approved expenses and card spend as journal entries.
Carry PO references on bills so Airbase can complete three-way matching on its side.
Fetch the SAP X-CSRF-Token before every write and bridge the SAP OAuth token with the Airbase bearer token.
Poll SAP on a schedule with backoff on rate limits, duplicate-invoice protection, and a full audit trail on every record.

Questions

Which direction does data move between SAP S/4HANA and Airbase?: Master data moves from SAP into Airbase, including vendors, GL accounts, and cost centers, so Airbase codes spend against real SAP dimensions. Approved transactions move the other way: bills post into SAP as supplier invoices, and reimbursements and card spend post as journal entries. Card transactions and GL accounts are read-only in Airbase, so ml-connector does not write them back from SAP.
Does SAP need anything set up before the connection works?: Yes. An SAP administrator must activate a Communication Arrangement for each OData service, such as the Business Partner and Supplier Invoice scenarios, which then supplies the OAuth 2.0 client ID, secret, and token URL. Without an active arrangement the service returns 404, so this is a prerequisite for any read or write.
How does the integration handle SAP write requirements and the lack of webhooks?: Every SAP write needs an X-CSRF-Token, so ml-connector fetches it with a GET, replays the mutating request with the token, and re-fetches on a 403. Because SAP has no native push webhooks, it polls OData on a schedule using a LastChangeDateTime filter and follows the nextLink for paging rather than waiting for a push.

Connect SAP S/4HANA and Airbase

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started