Microsoft Dynamics NAV and Procurify integration

What moves between them

The main flow moves from Procurify into Microsoft Dynamics NAV. Purchase orders and bills created in Procurify are read via polling on a schedule you set, typically aligned with your invoice processing cadence. Vendors from Procurify are matched against NAV vendor records by name or external ID, and account codes are mapped to NAV GL dimensions and cost centers. Once matched, the bill records post into NAV's general ledger as purchase invoice records with the correct vendor and GL account, ready for AP matching or batch posting.

How ml-connector handles it

ml-connector stores both credential sets encrypted and refreshes the Procurify OAuth token before it expires at the 24-hour mark. On the NAV side, it accepts the base URL for your NAV instance (cloud or on-premises), and if you use webhooks, it proactively renews the 3-day subscription before it expires to avoid gaps in event delivery. Procurify polling filters bills and purchase orders by last_modified date to capture only recent changes, reducing API volume. Vendors are mapped first using a match strategy you configure (exact name, fuzzy match, external ID, or manual mapping), and every unmatched vendor is flagged so you can resolve it before invoice posting. GL account codes from Procurify are validated against NAV's chart of accounts and cost center tables before posting, and bills with unmatched or invalid codes are held in an error state for your team to review. Every bill carries a full audit trail with timestamps, API responses, and validation results, so a failed posting can be inspected, fixed, and replayed without re-fetching from Procurify.

A real-world example

A mid-market distribution company runs Microsoft Dynamics NAV for their general ledger, vendor master, and procurement approvals. They also use Procurify for purchase requisitions, PO creation, and spend analytics across 12 warehouse locations. Before the integration, the AP team manually logged into both systems each week to reconcile bills in Procurify against NAV, and re-entered invoice details and cost allocations by hand. With NAV and Procurify connected, bills created in Procurify flow into NAV automatically with vendors already matched and GL codes validated, cutting invoice processing time from 4 hours per week to 20 minutes, and eliminating data entry errors.

What you can do

• •Poll bills and purchase orders from Procurify and post them into Microsoft Dynamics NAV as purchase invoice records.
• •Match Procurify vendors to NAV vendor records by name, external ID, or manual mapping, and flag unmatched vendors for review.
• •Map Procurify account codes to NAV GL accounts and cost centers so invoices post to the correct ledger lines.
• •Refresh Procurify OAuth tokens before expiry and renew NAV webhook subscriptions on a 3-day schedule to avoid lapses in data sync.
• •Maintain a full audit trail on every bill with validation results and API responses, so failed postings can be reviewed and replayed.

Questions

How does ml-connector handle the 3-day webhook subscription expiry in Microsoft Dynamics NAV?

ml-connector proactively renews NAV webhook subscriptions before they expire to prevent gaps in event delivery. If you prefer polling instead, ml-connector can poll NAV purchase invoices and vendors on a schedule you set, making the subscription renewal unnecessary.

Which direction does data move between Microsoft Dynamics NAV and Procurify?

The main flow is Procurify into NAV. Bills and purchase orders created in Procurify are read via polling and posted into NAV's general ledger. Vendors and account codes can be aligned in both directions so that NAV vendor updates reflect in Procurify and vice versa.

What happens if a bill has a vendor or account code that does not exist in Microsoft Dynamics NAV?

ml-connector validates vendors against NAV's vendor master and account codes against the chart of accounts and cost centers before posting. Bills with unmatched or invalid vendors or codes are held in an error state with details logged, so your AP team can resolve the mapping, update the master data if needed, and replay the posting without fetching from Procurify again.