Microsoft Dynamics GP and Brex integration

What moves between them

The main flow runs from Brex into Microsoft Dynamics GP. When a Brex accounting record is coded and ready, ml-connector reads it and posts the spend into GP's general ledger as a journal entry, mapped to the matching GP account number and segments. Vendor records can flow from GP into Brex so the Brex vendor directory used for bill pay stays aligned with the GP master. Accounting dimension values such as department or class are aligned so each posted line references segments that already exist in GP. Posted GP entries are not written back to Brex, and Brex transactions are read-only, so ml-connector treats Brex as the spend source and GP as the ledger of record.

How ml-connector handles it

ml-connector stores both credential sets encrypted and sends the Brex bearer token on every request, refreshing the OAuth2 token before it expires and watching the 90-day inactivity window on static user tokens. On the GP side it presents the customer's Windows domain account over Negotiate or NTLM to the SBA or SOAP endpoint the customer has exposed through their firewall or a local agent, since GP has no cloud address. It subscribes to the Brex ACCOUNTING_RECORD_READY_FOR_EXPORT webhook, verifies the Svix signature, then pulls the coded record and posts a GP journal entry, and after a successful post it marks the Brex record export_status as EXPORTED so the same spend is not posted twice. A scheduled poll backfills anything a webhook missed. GP accounts and segments are mapped first so every journal line lands on a valid account, and because Brex merchant names rarely match GP vendor names, vendor matching uses a fuzzy and cached layer. Brex rate limits return HTTP 429 and GP writes only apply to unposted batches in an open fiscal period, so ml-connector backs off, retries, and surfaces a period or posting error rather than failing silently. Every record carries a full audit trail and can be replayed if a GP post fails.

A real-world example

A mid-sized professional services firm of about 150 staff runs Microsoft Dynamics GP on a hosted server for its financials and gives employees Brex cards for software, travel, and client expenses. Before the integration, an accountant exported the Brex transaction feed each week, sorted it by category, and hand-keyed the totals into GP journals, then chased coding questions during every month-end close. With Microsoft Dynamics GP and Brex connected, each coded Brex accounting record posts into GP automatically against the right account and department segment, and the Brex vendor list stays aligned with the GP master. The weekly export-and-retype step is gone and close starts from spend that is already in the ledger.

What you can do

• •Post coded Brex card and expense accounting records into Microsoft Dynamics GP as GL journal entries against the right account numbers.
• •Align Brex accounting dimension fields with GP account segments so every posted line uses a valid combination.
• •Keep the Brex vendor directory in step with the Microsoft Dynamics GP vendor master for bill pay.
• •Authenticate Brex with its bearer token and GP with the customer's Windows domain account over its exposed endpoint.
• •Trigger on the Brex ready-for-export webhook, back off on rate limits, and keep a full audit trail with replay on every record.

Questions

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

The main flow is Brex into Microsoft Dynamics GP. Coded card and expense accounting records move from Brex into GP as journal entries, and vendor records can flow from GP into Brex for bill pay. Brex transactions are read-only and posted GP entries are not written back, so Brex is the spend source and GP is the ledger of record.

Does Brex create posted invoices or GL entries that GP can import directly?

No. Brex is a spend platform and has no native posted GL or AP document. What it provides is coded accounting records carrying a gl_account_id and dimension fields, and ml-connector maps those onto GP account numbers and segments, then posts them as GP journal entries rather than importing a ready-made GP document.

How does the integration reach an on-premises GP server that has no cloud URL and no webhooks?

The customer exposes their GP SBA or SOAP endpoint through a firewall or a local agent, and ml-connector authenticates with the dedicated Windows domain account GP requires. Because GP cannot push events, ml-connector is driven by the Brex ready-for-export webhook for timing and uses a scheduled poll to backfill, writing only to unposted batches in an open fiscal period.