Microsoft Dynamics 365 F&O and Basware integration

What moves between them

The transactional flow runs from Basware into Microsoft Dynamics 365 F&O. ml-connector reads coded and approved accountingDocuments from Basware and posts them into Dynamics as vendor invoice headers and lines, mapping the Basware coding lines to the matching Dynamics main accounts and financial dimensions. Master data runs the other way: vendors, main accounts, dimensions, and purchase orders are imported from Dynamics into Basware so its coding and matching panels reference values that already exist in the ERP. Once Dynamics posts a vendor payment, ml-connector confirms it back to Basware through paymentResponses. Dynamics owns the general ledger, so ml-connector never writes posted journal entries into Basware.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Basware side it requests a regional bearer token by sending the client id and secret as HTTP Basic auth, and selects the correct EU, US, AU, or CA base URL per customer. On the Dynamics side it requests an Entra ID client-credentials token scoped to the environment host and reissues it when a call returns 401, and it accepts the full operations.dynamics.com host as a credential since there is no shared URL. Vendors, main accounts, and dimensions are imported into Basware first so every invoice codes against values that already exist in Dynamics. When Basware webhooks are enabled, ml-connector verifies the X-BWAPI-Signature-256 HMAC-SHA256 over the raw UTF-8 body and acts on the AccountingDocuments task type as invoices reach WaitingForTransfer; otherwise it polls accountingDocuments on a schedule, paging through the continuation token returned in the response header. Because Dynamics has no idempotency key on OData writes and uses the InvoiceNumber plus VendorAccount natural key, ml-connector dedupes on that key and a BullMQ jobId so a re-read invoice is not double-booked. Vendor invoice writes are pre-posting only in Dynamics, so corrections are made before posting, and once the payment posts ml-connector calls paymentResponses to acknowledge transfer back to Basware. Both sides return HTTP 429 under load, so the connector honors the Retry-After header, backs off, and replays from a full audit trail if a downstream call fails.

A real-world example

A mid-sized manufacturer with around 600 employees runs Microsoft Dynamics 365 F&O for procurement and finance and uses Basware to capture and approve supplier invoices across several legal entities. Before the integration, AP staff exported approved invoices from Basware and keyed each header and coding line into Dynamics by hand, which slowed posting, introduced coding errors, and left vendor and account masters drifting apart between the two systems. With Microsoft Dynamics 365 F&O and Basware connected, each approved invoice posts into Dynamics against the right accounts and dimensions, vendors and the chart of accounts stay aligned, and posted payments are confirmed back to Basware. The re-keying step disappears and month-end close starts with AP already reconciled.

What you can do

• •Post coded and approved Basware invoices into Microsoft Dynamics 365 F&O as vendor invoice headers and lines.
• •Import Dynamics vendors, main accounts, dimensions, and purchase orders into Basware so coding lands on valid values.
• •Confirm posted vendor payments back to Basware through paymentResponses once Dynamics records them.
• •Bridge Microsoft Entra ID client-credentials tokens and Basware regional OAuth2 tokens, and verify HMAC-SHA256 webhooks.
• •Dedupe on the InvoiceNumber and VendorAccount natural key with retries and a full audit trail on every record.

Questions

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

Invoices move from Basware into Dynamics: coded and approved accountingDocuments post as vendor invoice headers and lines. Master data moves the other way, with vendors, main accounts, dimensions, and purchase orders imported from Dynamics into Basware so coding uses valid values. Dynamics owns the general ledger, so ml-connector confirms posted payments back to Basware but never writes posted journal entries into it.

Does Basware push approved invoices, or does ml-connector poll for them?

Both are supported. When a Basware subscription is active, ml-connector verifies the X-BWAPI-Signature-256 HMAC-SHA256 signature over the raw UTF-8 body and acts on the AccountingDocuments task type as invoices reach WaitingForTransfer. Otherwise it polls GET /v1/accountingDocuments on a schedule, paging through the continuation token returned in the response header. Dynamics itself is read by OData polling because its Business Events are unsigned lightweight stubs.

How does the integration avoid posting the same invoice twice in Dynamics?

OData writes in Dynamics have no idempotency key and use the InvoiceNumber plus VendorAccount natural key, so a duplicate create would raise a key violation. ml-connector dedupes on that natural key and a BullMQ jobId before posting, so a re-read or re-pushed invoice is not double-booked. Because vendor invoice writes are pre-posting only, corrections are made before the invoice is posted in Dynamics.