Acumatica and Chargebee integration

What moves between them

The main flow runs from Chargebee into Acumatica. After each billing cycle, ml-connector reads Chargebee invoices, payments, transactions, and credit notes and posts them into Acumatica as AR invoices, AP/AR payments, and GL journal transactions, mapped to the correct Acumatica GL accounts. Customer records move the same direction so the Acumatica customer master reflects new and changed Chargebee customers. Reference data such as currencies, items, and account mappings is aligned so each billing document lands on a valid Acumatica account. Posted GL and AR documents are not written back into Chargebee, which remains the billing system of record.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Chargebee side it sends the API key as Basic auth with the mandatory trailing colon and derives the base URL from the site name and region, so an EU site is never called against the US host. On the Acumatica side it accepts the full tenant URL per customer and the exact endpoint version, then wraps every field value as a JSON value object so Acumatica does not reject the payload with HTTP 400. It can receive Chargebee webhooks for invoice_generated, payment_succeeded, and credit_note_created, and because those payloads are unsigned it re-fetches each event by id before posting. Chargebee customers map to Acumatica customers and Chargebee invoices map to Acumatica AR invoices and journal lines on mapped GL accounts. Both APIs return HTTP 429 under load, so ml-connector honors the Chargebee Retry-After header and backs off against Acumatica license limits. Acumatica has no idempotency key, so ml-connector checks for an existing document by natural key before creating, and Chargebee webhook ids are deduplicated. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A growing B2B software company with around 150 employees bills several thousand customers through Chargebee on monthly and annual subscriptions, and runs Acumatica for finance and accounting. Before the integration, the finance team exported invoice and payment registers from Chargebee each month and re-keyed the revenue totals into Acumatica by hand, then spent the first days of close chasing differences between billed revenue in Chargebee and the AR and GL balances in the ledger. With Acumatica and Chargebee connected, each billing cycle's invoices, payments, and credit notes post into Acumatica automatically against the right GL accounts, and customer changes keep both systems aligned. Close starts with revenue and AR already reconciled, and the manual re-keying step is gone.

What you can do

• •Post Chargebee invoices and payments into Acumatica as AR invoices and GL journal transactions after every billing cycle.
• •Keep the Acumatica customer master aligned with new and changed Chargebee customers.
• •Bring Chargebee credit notes and refunds into Acumatica so adjustments reach the ledger.
• •Bridge Chargebee API-key Basic auth and Acumatica OAuth against the correct version-locked endpoint, with field values wrapped as Acumatica requires.
• •Trigger on Chargebee webhooks with event re-fetch, or poll on a schedule, with retries and a full audit trail on every record.

Questions

Which direction does data move between Acumatica and Chargebee?

The main flow is Chargebee into Acumatica. Invoices, payments, transactions, and credit notes move from Chargebee into Acumatica as AR invoices and GL journal entries, and customer records flow the same direction. Chargebee stays the billing system of record, so ml-connector does not write posted ledger documents back into Chargebee.

How does the integration handle Chargebee webhooks without an HMAC signature?

Chargebee does not sign webhook payloads with an HMAC header. ml-connector secures the endpoint with basic auth or a secret token in the URL, then re-fetches each event by id through the Chargebee events API before posting anything to Acumatica. Event ids are deduplicated so a retried delivery does not create a duplicate document.

How does ml-connector deal with Acumatica's version-locked endpoints and lack of an idempotency key?

ml-connector accepts the full Acumatica tenant URL and the exact endpoint version per customer, since a mismatched version returns HTTP 404. Because Acumatica has no idempotency-key header, it checks for an existing document by a natural key before creating one and uses upsert semantics where available, so a retried sync does not double-post.