Microsoft Dynamics 365 F&O and Tipalti integration

What moves between them

The outbound flow runs from Microsoft Dynamics 365 F&O into Tipalti. ml-connector reads approved vendor invoice headers and lines and posts them to Tipalti as bills with CreateOrUpdateInvoices, and reads new or changed vendors and creates or updates them as Tipalti payees. Payment status flows the other direction: Tipalti IPN callbacks and the payments API report when a payment is submitted, completed, or rejected, and ml-connector writes the matching vendor payment journal lines back into Dynamics. GL accounts and the financial dimension display value are aligned so every bill and payment line references an account that already exists on both sides. Tipalti runs the actual payments, so Dynamics is never asked to move money.

How ml-connector handles it

ml-connector stores both credential sets encrypted. It requests a Microsoft Entra ID bearer token for the Dynamics environment scope and refreshes it when a call returns 401, and for each Tipalti SOAP call it computes the HMAC-SHA256 key over the exact payer name, payee id, and timestamp. The payer name must match Tipalti exactly, so a casing or spacing difference is treated as an auth error rather than retried blindly. Vendor invoices are read by polling because the Dynamics Business Event for a posted invoice carries only identifiers and must be followed by an OData read, and only pre-posting headers are writable so the connector treats posted invoices as read-only. Vendors map to payees by account, and GL accounts plus the financial dimension string are mapped first so bills and payment journals land on valid accounts. Inbound IPN callbacks are verified by recomputing the HMAC over the posted parameters before a payment journal line is written, and Tipalti can deliver the same IPN more than once, so the payment id is used to deduplicate. Dynamics returns HTTP 429 with Retry-After under service protection limits and Tipalti caps SOAP reads at 250 records per call, so the connector pages and backs off accordingly. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized engineering and field-services firm of around four hundred staff runs Microsoft Dynamics 365 F&O for procurement and finance and pays a large base of domestic and overseas subcontractors through Tipalti. Before the integration, the AP team exported approved invoices from Dynamics each week, re-entered them into Tipalti to schedule payment, then watched the Tipalti dashboard and manually marked invoices paid back in Dynamics once funds went out. With the two systems connected, approved vendor invoices flow into Tipalti as bills automatically, new subcontractors are created as payees, and Tipalti payment confirmations post vendor payment journal lines back into Dynamics. The double entry disappears and the ledger shows real payment status without anyone copying it across.

What you can do

• •Send approved vendor invoices from Microsoft Dynamics 365 F&O into Tipalti as bills for global payment.
• •Create and update Tipalti payees from new and changed Dynamics 365 F&O vendor records.
• •Write vendor payment journal lines back into Dynamics 365 F&O from Tipalti payment status.
• •Bridge Microsoft Entra ID OAuth tokens to the Tipalti HMAC-SHA256 signature and verify each IPN with the same key.
• •Map GL accounts and the financial dimension string so every bill and payment lands on a valid account.

Questions

Which direction does data move between Microsoft Dynamics 365 F&O and Tipalti?

Approved vendor invoices and vendor records move from Dynamics 365 F&O into Tipalti as bills and payees. Payment status moves back the other way, where Tipalti IPN callbacks and the payments API drive vendor payment journal lines in Dynamics. Tipalti runs the actual payments, so the connector never asks Dynamics to move money.

How does the integration handle the two different authentication schemes?

Dynamics 365 F&O uses OAuth2 client credentials through Microsoft Entra ID, while the Tipalti SOAP API uses an HMAC-SHA256 signature built from the payer name, payee id, and timestamp. ml-connector requests and refreshes the Entra ID bearer token and computes a fresh Tipalti signature per call, and it verifies inbound IPN callbacks by recomputing the HMAC with the same key. The Tipalti payer name must match exactly, so a mismatch is surfaced rather than retried.

Does the connection use webhooks or polling for invoices?

Vendor invoices are read by polling. The Dynamics Business Event for a posted invoice carries only identifiers and would require a follow-up OData read, so the connector reads approved invoices on a schedule instead. Tipalti payment status, however, arrives by IPN callback, verified by signature, with a scheduled read of the payments API as a backstop for any missed event.