Microsoft Dynamics 365 Business Central and Tipalti integration

What moves between them

The main flow runs from Microsoft Dynamics 365 Business Central into Tipalti. Approved vendors are pushed into Tipalti as payees, and posted purchase invoices are pushed in as payable invoices, mapped by vendor number and invoice number. Payment status then flows back from Tipalti into Business Central: when Tipalti reports a payment completed, ml-connector records the vendor payment through a Business Central payment journal so the open bill is cleared and the ledger reflects it. GL account codes are aligned in both directions so invoice lines and payments land on accounts that exist on each side. Tipalti executes the actual payments, so Business Central is never used to move money directly.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On every Tipalti SOAP call it builds the HMAC-SHA256 key from the exact payer name, payee id, and timestamp, and for REST calls it uses the OAuth 2.0 bearer token or the static x-api-key where a Procurement endpoint requires it. On the Business Central side it requests an Entra ID token with the client credentials grant and refreshes it when a call returns 401. New and changed vendors and posted purchase invoices are detected through Business Central subscriptions, with a delta poll using a lastModifiedDateTime greater-than filter as a backstop, since those notifications carry no payload and must be fetched. Only posted invoices are pushed, because drafts are not yet payable. Vendors map to Tipalti payees by the Business Central vendor number used as the payee idap, and the upsert functions make re-sends safe. Payment results are picked up from Tipalti IPN events and reconciled with a GetUpdatedPayments poll, then written back as vendor payment journal lines applied to the matching invoice. Known edge cases are handled: the payer name must match the Tipalti account string exactly or the signature fails silently, updating a payee address forces the payee to re-verify their payment method, Business Central subscriptions expire every three days and are renewed before expiry, and SOAP reads return at most 250 records per call so large pulls are paged. Tipalti Procurement REST also limits some calls to a few per minute, so ml-connector backs off and retries on throttling.

A real-world example

A mid-sized software company with about 300 employees runs Microsoft Dynamics 365 Business Central for finance and purchasing and pays contractors and vendors in a dozen countries. Before the integration, the AP team approved bills in Business Central, then re-entered each one into Tipalti by hand to run payment, and later typed the payment confirmations back into Business Central to close the open invoices. Cross-border payees also needed tax and banking details collected outside the ERP. With the two systems connected, approved purchase invoices and their vendors move into Tipalti automatically, Tipalti handles payee onboarding and pays them, and the completed payments post back into Business Central against the right invoices. The double entry disappears and the open payables list reflects what Tipalti has actually paid.

What you can do

• •Push approved Business Central vendors into Tipalti as payees, keyed by vendor number.
• •Send posted Business Central purchase invoices into Tipalti as payable invoices for payment.
• •Record vendor payments back in Business Central when Tipalti reports a payment completed.
• •Bridge Business Central Entra ID OAuth with Tipalti's HMAC-signed SOAP and OAuth REST calls.
• •Align GL account codes on both sides so invoices and payments land on valid accounts.

Questions

Which direction does data move between Microsoft Dynamics 365 Business Central and Tipalti?

Vendors and posted purchase invoices move from Business Central into Tipalti, where payment is executed. Payment status moves back from Tipalti into Business Central so vendor payments are recorded and open bills are cleared. GL account codes are aligned in both directions, but the money itself is always paid by Tipalti, not by Business Central.

How does ml-connector handle Tipalti's HMAC signing and Business Central's OAuth token?

For Business Central, ml-connector uses the OAuth 2.0 client credentials grant against your Entra ID tenant and refreshes the token when a call returns 401. For Tipalti SOAP calls, it computes the HMAC-SHA256 key from your exact payer name, the payee id, and a timestamp on every request. The payer name must match the Tipalti account string exactly, because a mismatch fails the signature silently rather than returning a clear error.

Are Business Central webhooks enough, or is polling needed too?

Business Central subscriptions notify the connector when vendors, purchase invoices, or payment journals change, but the notification is only a change signal with no data, so ml-connector fetches the record afterward. Those subscriptions also expire every three days and are renewed before expiry. A delta poll on lastModifiedDateTime runs as a backstop, and payment status from Tipalti is collected from IPN events plus a GetUpdatedPayments poll.