Sage 100 and Brex integration
Sage 100 runs your accounting and ERP on a Windows server in your own building. Brex runs corporate cards, expenses, and bill pay in the cloud. Connecting the two moves coded spend out of Brex and into the Sage 100 general ledger and accounts payable without re-keying. Once Brex finishes coding a card or expense transaction, ml-connector posts it into Sage 100 against the right GL account and cost center, and keeps vendors and GL segments aligned on both sides. Because Sage 100 has no cloud API, ml-connector reaches it through a local agent on your server and moves data on a schedule you control.
What moves between them
The main flow runs from Brex into Sage 100. When Brex finishes coding a card or expense transaction, ml-connector reads the accounting record and posts it into Sage 100 through the local agent, either as an AP invoice against the matching vendor or as a GL journal entry, allocated to the correct segmented GL account and cost center. Reference data moves the other way: Sage 100 vendors flow into the Brex vendor directory and Sage 100 GL accounts and segments flow into Brex custom fields, so Brex coding only ever uses dimensions that exist in Sage 100. After each record posts, ml-connector marks the Brex accounting record as EXPORTED so it is not picked up twice. Polling runs every fifteen minutes for spend; vendor and GL alignment runs hourly to daily.
How ml-connector handles it
ml-connector stores both credential sets encrypted and sends the Brex Bearer token on every request, watching for the 90-day inactivity expiry so a quiet token does not lapse. On the Sage 100 side it calls the local agent over HTTPS using the agent API key and the three-character company code, since Sage 100 lives on the customer server with no shared base URL and often a self-signed certificate, so TLS verification is configurable. Brex sends an ACCOUNTING_RECORD_READY_FOR_EXPORT webhook verified with Svix HMAC-SHA256, and a scheduled poll backfills anything a webhook missed. Each Brex record maps to a Sage 100 AP invoice or GL journal entry, with the segmented GL account parsed defensively because segment count varies per company, and the APDivisionNo plus VendorNo pair used as the AP key. Brex merchant names rarely match Sage 100 vendor names, so a fuzzy match and cache layer resolves the vendor before posting. Because Sage 100 has no external idempotency key, ml-connector checks for an existing invoice before insert; Brex transfers use the required Idempotency-Key header. Sage 100 record locks and Brex 429 limits are both retried with exponential backoff, and every record carries a full audit trail and can be replayed if a post fails.
A real-world example
A regional construction supplier with about 120 employees runs Sage 100 on a server in its main office for accounts payable and the general ledger, and gives field managers Brex cards for fuel, tools, and job-site purchases. Before the integration, an accounting clerk exported Brex statements each week and hand-keyed every card charge into Sage 100, guessing which job and GL account each line belonged to, and month-end close stalled while uncoded card spend sat outside the ledger. With Sage 100 and Brex connected, managers code purchases in Brex against jobs and departments that were pushed up from Sage 100, and each coded transaction posts into the Sage 100 ledger automatically through the local agent. The weekly re-keying is gone and close starts with card spend already in the right accounts.
What you can do
- Post coded Brex card and expense transactions into Sage 100 as AP invoices or GL journal entries through a local agent.
- Allocate every posting to the correct segmented Sage 100 GL account and cost center.
- Push Sage 100 vendors and GL segments into Brex vendors and custom fields so Brex coding uses valid dimensions.
- Receive the Brex ACCOUNTING_RECORD_READY_FOR_EXPORT webhook, verified by Svix HMAC-SHA256, with scheduled polling as a backstop.
- Bridge the Brex Bearer token and the local agent API key, retry on locks and 429s, and keep a full audit trail on every record.
Questions
- Which direction does data move between Sage 100 and Brex?
- Coded spend moves from Brex into Sage 100. Brex card and expense accounting records post into the Sage 100 general ledger and accounts payable, while Sage 100 vendors and GL segments flow back into Brex so coding stays valid. After each record posts, ml-connector marks the Brex record as EXPORTED so it is never processed twice.
- Sage 100 is on-premises, so how does a cloud connector reach it?
- Sage 100 has no cloud API, so a lightweight Windows agent runs on your Sage 100 server and exposes an HTTPS endpoint that ml-connector calls with an API key. The agent wraps the Business Object Interface, which is the only path with full AP, GL, and vendor write access. ml-connector also handles the three-character company code and configurable TLS for self-signed certificates.
- Does Brex give Sage 100 real AP invoices and purchase orders?
- Brex is a spend platform and has no purchase orders or supplier invoices of its own. What it provides is coded accounting records, card and cash transactions, and a vendor directory, and ml-connector turns each coded record into a Sage 100 AP invoice or GL journal entry. Because Brex merchant names rarely match Sage 100 vendor names, a fuzzy match layer resolves the vendor before posting.
Related integrations
More Sage 100 integrations
Other systems that connect to Brex
Connect Sage 100 and Brex
Free to use. Add your credentials, ping your real systems, and see if we fit.
Get started