Sage 100 and Wise integration

What moves between them

The flow runs from Sage 100 AP into Wise. ml-connector polls Sage 100 at a schedule you set (commonly every 4 hours for batch payouts) and reads AP invoices with status unpaid or ready-for-payment. Each unpaid invoice is transformed into a Wise transfer order: the vendor is looked up or registered as a Wise recipient, a quote is fetched for the invoice amount and currency, the transfer is created, and payment is initiated. Once the Wise transfer launches, ml-connector records the transfer ID in Sage 100 AP and polls Wise webhook events for state changes. When a payout succeeds, ml-connector marks the invoice as paid and posts a GL journal entry crediting AP and debiting cash. If a payout fails, ml-connector flags the invoice as failed-payout and surfaces the Wise error reason in Sage 100 audit.

How ml-connector handles it

ml-connector stores Sage 100 username-password and Wise OAuth credentials encrypted and bridges the authentication gap: it refreshes the Wise bearer token every 12 hours (before expiry) and presents Sage 100 credentials on each SOAP or BOI call. Because Wise requires a 4-step sequence for each transfer, ml-connector caches active Wise recipients so it does not re-register the same vendor on every poll. When Sage 100 SOAP reports no AP data (due to the limited eBusiness Web Services surface), ml-connector falls back to the local agent endpoint for full AP/GL access. Wise webhooks push state changes, but ml-connector also polls for resilience: if a webhook is missed or delayed, the next scheduled poll catches up. When Wise returns a 429 rate-limit, ml-connector backs off exponentially and retries. Sage 100 GL accounts use multi-segment format (e.g., 4000-01-00) that varies by customer config, so ml-connector requires a one-time mapping of Sage 100 GL codes to Wise transfer source accounts before the first payout. Quotes expire within Wise's window, so ml-connector fetches a fresh quote on each poll rather than reusing one. Transfer recipients in Wise are immutable, so if a vendor's bank account changes, ml-connector flags it for manual recipient deletion and re-registration via Wise's UI.

A real-world example

A mid-sized import distributor runs Sage 100 for AP and inventory. They source goods from vendors across Europe and Asia and need to pay invoices in foreign currencies every week. Before Wise integration, the AP team exported unpaid invoices from Sage 100, manually entered each into Wise, tracked payout status in a spreadsheet, and re-entered paid invoices back into Sage 100 at month-end to close the AP subledger. With Sage 100 and Wise connected, the weekly poll automatically finds all unpaid invoices in Sage 100, initiates transfers in Wise at the latest exchange rate, and marks invoices paid once Wise confirms the payout. The AP team no longer needs to re-key; they review the audit log in ml-connector to spot failed transfers and follow up with vendors or banks.

What you can do

• •Poll Sage 100 AP invoices on a schedule and automatically initiate Wise transfers for international vendors.
• •Execute Wise's 4-step transfer flow (quote, recipient, transfer order, fund) without manual intervention.
• •Reconcile Wise payout status back into Sage 100 AP records so you always know which invoices are paid, pending, or failed.
• •Handle Sage 100's local-agent and SOAP authentication, and bridge to Wise OAuth 2.0 with automatic token refresh.
• •Retry on Wise rate limits and webhook delays, with full audit trail and error replay on failed payouts.

Questions

How does ml-connector handle Sage 100's on-premises architecture and lack of cloud API?

ml-connector deploys a local Windows service agent on the customer's Sage 100 server that wraps the BOI COM layer and exposes AP, GL, and vendor data over a secure internal endpoint. ml-connector polls this agent on your schedule to read unpaid invoices. For queries that eBusiness Web Services SOAP can handle (AR and sales orders), ml-connector calls the SOAP endpoint directly; for AP and GL, it uses the agent.

What happens if a Wise payout fails or is delayed?

ml-connector receives the failure via Wise webhooks (transferspayout-failure or transfersstate-change) and marks the AP invoice as failed-payout with the Wise error reason logged in audit. If a webhook is delayed or missed, the next scheduled poll re-queries Wise and catches up. You can then review the failed transfer in ml-connector, adjust the Wise recipient or amount if needed, and trigger a manual retry.

How are Sage 100 GL accounts mapped to Wise transfer source accounts?

Sage 100 GL accounts use a multi-segment format (e.g., 4000-01-00) that varies by customer, so ml-connector requires a one-time config mapping your GL codes to Wise source account IDs before the first payout. This ensures cash debits land on the correct GL account for each currency or cost center.