Microsoft Dynamics GP and Chargebee integration

What moves between them

The flow runs from Chargebee into Microsoft Dynamics GP. ml-connector reads paid and posted invoices, the payments recorded against them, and credit notes from Chargebee and posts them into GP as receivables invoices, cash receipts, and credit documents, mapped to the matching GP customers and GL accounts. Customer records flow the same direction so the GP customer master reflects Chargebee billing customers, with the billing email, company, and currency carried across. Because Chargebee has no general ledger, GL postings stay in Dynamics GP and ml-connector never writes ledger entries back into Chargebee, which is treated as the billing source of record.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Chargebee side it sends the API key as the Basic Auth username with an empty password, and derives the correct US, EU, or AU base URL from the configured region so a key is never sent to the wrong data center. On the GP side it accepts the full SBA or SOAP endpoint URL per customer along with the Windows domain, user, and the company database name, since GP is on-premises and publishes no shared address, and it reaches that server through the customer's firewall opening or a local agent. Because GP has no webhooks and is the write target, ml-connector takes Chargebee invoice_generated, payment_succeeded, and credit_note_created webhooks as triggers and re-fetches each event by id rather than trusting the pushed body, then falls back to a scheduled poll to backfill anything a webhook missed. Customers are mapped first, so every invoice references a GP customer that already exists. Each new receivables document is written into an unposted GP batch so posted records stay read-only, and the target fiscal period must be open or GP rejects the write. Chargebee returns HTTP 429 with a Retry-After header when a rate limit is hit, which ml-connector honors with exponential backoff, while GP writes are paced to a few parallel calls so polling does not slow the customer's SQL Server. Chargebee has no idempotency-key header, so ml-connector dedupes on the Chargebee event id and a BullMQ jobId, and GP itself rejects a duplicate document number rather than silently double-booking. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A subscription software company with roughly 120 employees bills its customers monthly in Chargebee and keeps its books in Microsoft Dynamics GP on a server hosted by its IT partner. Before the integration, an accountant exported the Chargebee invoice and payment registers each month and hand-keyed the receivables totals into GP, which left invoices posted days late, customer records drifting apart between the two systems, and the first part of every close spent chasing differences between billed revenue and the AR balance in the ledger. With Microsoft Dynamics GP and Chargebee connected, each paid invoice and its payment flow into GP within the polling window, posted to an unposted batch for review and matched to the right customer and account, and credit notes post as credit documents. The re-keying step is gone and close starts with receivables already reconciled.

What you can do

• •Post Chargebee invoices, payments, and credit notes into Microsoft Dynamics GP as receivables and GL documents.
• •Keep the GP customer master aligned with Chargebee billing customers, including email, company, and currency.
• •Bridge Chargebee Basic Auth and the Windows-authenticated GP SBA or SOAP endpoint on the customer's server.
• •Take Chargebee webhooks as triggers, re-fetch each event by id, and write into unposted GP batches only.
• •Dedupe on the Chargebee event id and a jobId, honor Retry-After backoff, and keep a full audit trail on every record.

Questions

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

The flow is Chargebee into Microsoft Dynamics GP. Invoices, payments, credit notes, and customer records move from Chargebee into GP as receivables documents, cash receipts, and customers. Chargebee has no general ledger of its own, so the GL stays in Dynamics GP and ml-connector never writes ledger entries back into Chargebee.

How does the integration reach an on-premises Dynamics GP server, and does it use webhooks?

Dynamics GP is on-premises with no cloud endpoint, so ml-connector connects to the customer's SBA REST or SOAP Web Services URL using the Windows domain account mapped to a GP user, reached through a firewall opening or a local agent. GP has no webhooks, so it is only the write target. Chargebee does the pushing: its invoice and payment webhooks trigger the sync, and a scheduled poll backfills anything that was missed.

How does the integration avoid posting duplicate or invalid documents in GP?

Chargebee has no idempotency-key header, so ml-connector deduplicates on the unique Chargebee event id and a BullMQ jobId before it writes, and it re-fetches each event by id rather than trusting the pushed payload. New documents are written into unposted GP batches so posted records stay protected, the target fiscal period must be open, and GP itself rejects a duplicate document number rather than silently double-booking.