Microsoft Dynamics 365 Business Central: template-free PO capture

Business Central (formerly NAV) is Microsoft’s ERP for the mid-market. OrderPilot’s BC connector uses the Standard API v2.0 and is production-ready within a day — regardless of whether you run cloud SaaS, cloud BYOL, or on-prem (with API access).

Why template-free matters for BC customers

Business Central is used across a wide spectrum: from manufacturers with hundreds of suppliers to trading firms that receive daily orders in 10+ formats. Rule-based email parsers (like Mailparser) and template-based OCR (Kofax, ABBYY) force you to build a template or rule set per supplier. For 200 suppliers × 3 order formats each = 600 templates to maintain.

OrderPilot’s AI works without templates. A new supplier with a never-before-seen PDF layout is read correctly on day one because the model trains on semantic meaning, not on coordinates on a page.

Connector architecture

Business Central exposes multiple API surfaces. OrderPilot uses the Standard API v2.0 (the documented, stable layer) and optionally Custom APIs for customer-specific fields.

Flow:

1. Azure AD / Entra ID OAuth — A service-to-service connection via an App Registration with Financials.ReadWrite.All scope.
2. Environment + Company selection — Per OrderPilot workspace you link one environment (Production / Sandbox) and a company. Multi-company is supported.
3. Sync + write — Vendors (/vendors), Items (/items), and Dimensions (/dimensionValues) are synced nightly. Validated POs are created via POST /purchaseOrders.

Vendor matching

Business Central uses the Vendor No. concept (primary key, often a letter+digit code). OrderPilot matches incoming POs by:

1. Email domain (exact)
2. VAT number (VATRegistrationNumber)
3. Address fuzzy match
4. Name fuzzy match (review required)

Unmapped vendors land in a queue. One click links the incoming order to the correct Vendor No. — OrderPilot remembers this per sender domain.

Item No. resolution

BC’s Item No. is strict — a requested “bolt M12x80 galvanized” has to be translated to “item 1000-M12-80-GV”. This is where domain-generic PO tools fail and OrderPilot wins. Our matching model combines:

• Supplier-specific Item Reference tables (the equivalent of Item Cross Reference) if they exist in BC.
• Textual fuzzy matching on Description and Description 2.
• SKU patterns and aliasing you configure per supplier (or globally).

Unmatched items go to the review queue. If an item does not exist in BC yet, OrderPilot will not auto-create it — the operator does that in BC and links it in OrderPilot afterward.

Dimensions

BC’s Dimensions (e.g. DEPARTMENT, PROJECT, CUSTOMER) are supported per line. OrderPilot derives them from:

• Rule-based mapping (e.g. “Everything from supplier X → DEPARTMENT = PURCHASING”)
• The requester’s email domain or OU
• Explicit text in the PO (“Project: ABC123”)

PO creation flow

A validated PO posts to BC as:

POST /api/v2.0/companies({companyId})/purchaseOrders
{
  "vendorId": "<vendor-guid>",
  "orderDate": "2026-04-20",
  "requestedReceiptDate": "2026-04-28",
  "purchaser": {
    "code": "...",
  }
}

// Then per line:
POST /api/v2.0/companies({companyId})/purchaseOrders({orderId})/purchaseOrderLines
{
  "itemId": "<item-guid>",
  "quantity": 10,
  "unitCost": 129.50,
  "lineType": "Item"
}

After creation the PO sits in BC as “Open”. Posting (the ledger-commit step) is done by the customer in BC — OrderPilot delivers a validated but not yet posted PO, in line with Microsoft’s best practice for workflow separation.

Idempotency

Per OrderPilot PO we store the BC id (GUID). Retries check for existence before posting. If a PO is manually deleted in BC, OrderPilot detects this on the next sync and flags the OrderPilot PO as “needs re-post”.

Cloud vs on-prem

• SaaS cloud — Default, recommended. Full API v2.0 availability.
• Cloud BYOL — Works identically to SaaS, same API.
• On-prem (BC 14+) — Works if the Service Tier APIs are publicly accessible (typically behind VPN or IP whitelisting). For older NAV installations (pre-BC 14) a middleware/adapter is needed; reach out.

What you don’t get

• No changes to Posted Documents. BC locks posted POs; OrderPilot works only with Open documents.
• No automatic item creation. Unknown items are not automatically created in BC — that’s a master-data decision your team makes.
• No custom table extensions out of the box. If your team has customizations (custom fields, AppSource extensions), we can map them via Custom APIs — that’s implementation work.

FAQ

Does this work with multiple companies? Yes, multi-company is supported. Per OrderPilot rule you pick which company an incoming PO is assigned to.

And with multiple environments (Production + Sandbox)? You can link sandbox + production in parallel for testing. Production writes are locked down by default until you explicitly enable them.

How long does implementation take? Standard: 1 business day — Entra ID App Reg, OAuth, vendor/item/dimension mapping, and 20-50 test orders. Complex landscape with customizations: 2-5 days.