Sage 300 and BILL integration

What moves between them

The integration pulls vendor and bill data from BILL via webhooks or scheduled GET calls to /v3/vendors and /v3/bills. Each vendor is mapped to a Sage 300 APVendor record with matching vendor number and GL account defaults. Each bill in BILL is converted into a Sage 300 APInvoiceBatch with line items mapped to the correct GL accounts and vendor groups. Invoices flow from BILL into Sage 300 only; Sage 300 does not write payments back to BILL, since BILL remains the source of truth for AP and payment status. The sync runs on a scheduled cadence, typically after bills are approved in BILL.

How ml-connector handles it

ml-connector stores the Sage 300 Basic Auth credentials encrypted and constructs the Authorization header on every request with the uppercase username and password. It polls the Sage 300 instance using the customer's unique API base URL since Sage 300 publishes no shared cloud endpoint. On the BILL side, ml-connector registers webhook subscriptions for bill.created and vendor.created events, validates each incoming webhook using HMAC-SHA256 signature verification against the stored securityKey, and refreshes the BILL session token when login returns an authentication error. When a bill arrives from BILL, ml-connector looks up or creates the matching vendor in Sage 300, maps each invoice line item to a Sage 300 GL account based on the line expense category or a configured mapping table, and posts the invoice batch into Sage 300's APInvoiceBatches endpoint. IIS rate limits or AppPool timeouts on large sync runs are handled by implementing exponential backoff and limiting batch sizes. Every operation is logged with invoice number, vendor, GL account, and posting status so failed records can be replayed if needed.

A real-world example

A mid-sized professional services firm runs Sage 300 on-premise for accounting and operations, and uses BILL for centralized AP and vendor management across multiple departments. Before the integration, invoices arrived in BILL and were printed or exported as CSVs for manual entry into Sage 300 by the accounting team. This created a week of lag between BILL invoice approval and GL posting, and reconciliation required matching BILL payments against Sage 300 transaction dates. With Sage 300 and BILL connected, each approved invoice posts into Sage 300 automatically within minutes of approval, and vendors created in BILL flow into Sage 300 the same day. The accounting team now verifies GL postings instead of re-entering data, and month-end close is two days faster because the AP subledger and GL are already aligned.

What you can do

• •Sync vendors from BILL into Sage 300's APVendor master, creating new vendor records and updating existing ones with current GL defaults.
• •Post BILL approved invoices into Sage 300 APInvoiceBatches with line items mapped to the correct GL accounts and vendor groups.
• •Receive bill and vendor change notifications from BILL via webhooks with HMAC-SHA256 signature verification.
• •Authenticate Sage 300 with Basic Auth credentials converted to uppercase per API requirements, and BILL with session token login and automatic token refresh.
• •Poll and retry with exponential backoff to handle Sage 300 IIS rate limits and BILL session token expirations, logging every operation for audit and replay.

Questions

What data flows between Sage 300 and BILL?

Vendors and bills flow from BILL into Sage 300's AP module. Each bill is posted as an APInvoiceBatch with line items mapped to the correct GL accounts. Sage 300 does not send data back to BILL because BILL remains the source of truth for AP and payments. Periodic reconciliation between the two systems ensures vendors and GL accounts remain aligned.

How does ml-connector handle Sage 300's Basic Auth and uppercase username requirement?

ml-connector stores the Sage 300 API username and password encrypted. On every request, it constructs the Basic Auth header by base64-encoding the uppercase USERNAME:PASSWORD pair and including it in the Authorization header. This is performed automatically for all Sage 300 API calls without requiring customer intervention.

Does ml-connector work with Sage 300 deployments hosted on customer premises?

Yes. Sage 300 is self-hosted on Windows IIS, so each customer exposes their own API endpoint over HTTPS. ml-connector accepts the customer's unique Sage 300 base URL and routes all requests there. The customer is responsible for ensuring the Sage 300 instance is accessible from ml-connector and that IIS is configured with Anonymous Authentication enabled and Windows Authentication disabled.