Sage 100 and BILL integration

What moves between them

The main flow runs from Sage 100 into BILL. ml-connector reads approved AP invoices and their vendors from Sage 100 through the local agent and creates the matching vendors and bills in BILL so they can be paid. Payment status flows back the other direction: as BILL processes a payment, ml-connector reads the result and records it against the original invoice in Sage 100 accounts payable under the correct AP division and vendor number. Vendor master data is aligned in both directions so identifiers stay consistent. Purchase orders stay in Sage 100, because BILL has no purchase order object.

How ml-connector handles it

ml-connector stores both credential sets encrypted. It calls the Sage 100 local agent over HTTPS, passing the company code on every request, and re-authenticates the BILL session whenever a call returns 401, since BILL signals an expired session as an auth error rather than a clear code. Because Sage 100 cannot push events, bills and vendors are found by polling DateLastUpdated and InvoiceDate on a schedule, while BILL payment and bill webhooks, verified by HMAC-SHA256, trigger faster updates where they are enabled. Sage 100 vendor numbers map to BILL vendor IDs and segmented GL account keys map to BILL chart of accounts entries, which are aligned first so every bill line lands on a valid account. Neither system offers an idempotency key, so the vendor and invoice number pair on the Sage 100 side and the entity ID returned by BILL are used to avoid duplicate creates. BILL allows only three concurrent requests per org and returns a rate limit code when exceeded, so calls are queued and retried with backoff, and Sage 100 record locks during high-frequency writes are retried the same way.

A real-world example

A mid-sized construction supply distributor with about 120 staff runs Sage 100 on a Windows server for purchasing, inventory, and the general ledger, and pays roughly 400 vendor bills a month. Before the integration the accounts payable clerk entered each approved bill into BILL by hand to run the payment, then typed the payment date and check or ACH reference back into Sage 100, and month-end close meant chasing bills that were paid in BILL but never marked paid in the ledger. With Sage 100 and BILL connected, approved bills and their vendors flow into BILL automatically and the completed payment posts back into Sage 100 against the right vendor and AP division. The double entry is gone and the AP aging in Sage 100 matches what BILL actually paid.

What you can do

• •Create vendors and AP bills in BILL from approved Sage 100 invoices read through the local agent.
• •Record completed BILL payments back into Sage 100 accounts payable against the original invoice, AP division, and vendor number.
• •Keep vendor master data aligned across Sage 100 and BILL so every bill points at a known vendor.
• •Map Sage 100 segmented GL account keys to BILL chart of accounts entries before any bill is created.
• •Bridge the Sage 100 company logon and the BILL session token, refreshing the session on expiry, with retries and a full audit trail on every record.

Questions

Which direction does data move between Sage 100 and BILL?

The main flow is Sage 100 into BILL: approved AP bills and their vendors move out so BILL can pay them. Payment status flows back into Sage 100, where ml-connector records each completed payment against the original invoice. Vendor records are aligned in both directions so identifiers stay consistent.

Why does Sage 100 need a local agent instead of a direct API call?

Sage 100 is on-premises and has no cloud API. Its full accounts payable, vendor, and general ledger access lives in the Business Object Interface, a COM layer that runs only on the Sage 100 server and cannot be called over the internet. A local Windows agent wraps that interface and exposes an HTTPS endpoint ml-connector reaches, which is the only way to get full AP write access with business rules enforced.

How are duplicate bills and payments prevented when neither system has an idempotency key?

Neither Sage 100 nor BILL accepts an external idempotency key, so ml-connector handles it at the connector level. On the Sage 100 side the vendor number and invoice number form a natural unique key that is checked before any create, and on the BILL side the entity ID returned on creation is stored and used to detect and skip a re-create. Payment records are checked the same way before a payment is recorded back into Sage 100.