# AI for Business Central Purchasing: Questions, Exceptions and Draft Orders on Your Own Data

> Source: https://netray.co/erp-ai/business-central-purchasing-ai
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: AI for ERP

## Short answer

AI for Business Central purchasing connects a language model to the Purchase Header, Purchase Line, Vendor and posted receipt data through the standard API v2.0 and OData web services, so buyers can ask which orders are late, which vendors are drifting, and what is waiting for invoice match. Answers cite the records behind them, access is read-only by default, and any draft order or change goes through a human before it posts.

## Kind

use-case

## Erp Family

microsoft

## Erp Products

- Dynamics 365 Business Central

## Industries

- Manufacturing
- Distribution

## Region

Global

## Persona

Purchasing Manager

## Eyebrow

Business Central purchasing AI

## Intro

Business Central purchasing looks simple on the surface: a vendor, a purchase order, a receipt, an invoice. In a working manufacturer or distributor it is a layer of purchase quotes, blanket orders, drop shipments, special orders, item charges, partial receipts and landed cost, all sitting in Purchase Header and Purchase Line with posting groups that the finance team cares about a great deal. A buyer who owns three hundred open lines cannot see the problem lines without building a filtered page for each question.

The usual response is to export to Excel or build Power BI reports. Both help, but both are one question at a time, built by someone who understood the question in advance. The question that actually arrives on Tuesday morning is different: which of my open lines for the aluminium extrusion supplier are promised after the need date of the sales orders they feed, and what did that vendor do on the last ten orders? That question touches purchase lines, vendor ledger history, and demand.

Microsoft is adding Copilot features to Business Central, and for many SaaS tenants they will cover document drafting and summaries. They are tied to the tenant and to Microsoft's cloud processing, and they do not reach your supplier scorecards, shared drives of vendor agreements, or a quality system on another network. This page covers the pattern where a private or tenant-controlled model reads Business Central through its supported APIs and answers purchasing questions with citations.

The point is not to take purchasing decisions away from buyers. It is to remove the hour a day spent finding the lines that need a decision, so the human time goes to expediting, negotiating and approving, which is where it creates value.

## Pain Points

### Late lines are found by hand

**Detail:** Expected Receipt Date, Promised Receipt Date and Requested Receipt Date live on Purchase Line, and each buyer builds personal filters to find slipping lines. Nobody sees the combined picture across vendors until a production order starves.

### Planning suggestions need judgment

**Detail:** The Requisition Worksheet and Planning Worksheet produce action messages (new, reschedule in, reschedule out, cancel). Planners carry out hundreds at a time with little time to check vendor behaviour, MOQs, or whether a contract price is about to change.

### Three-way match exceptions pile up

**Detail:** Posted receipts, vendor invoices and purchase orders disagree on quantity, price or item charges. Accounts payable works through them on spreadsheets, and the buyer is asked the same questions repeatedly.

### Vendor performance is anecdotal

**Detail:** On-time and in-full rates require joining purchase lines to posted receipts and quality records. Few teams have it as a live number, so supplier reviews run on memory and the loudest complaint.

### Price and terms knowledge is scattered

**Detail:** Price lists, Item Vendor catalog entries, payment terms on the vendor card and negotiated agreements in PDFs or email do not agree. Buyers pay different prices for the same item without knowing.

## Use Cases

### Late and at-risk order digest

**Description:** A daily summary per buyer of open purchase lines whose promised date is after the date the demand needs them, ranked by what they block, with the vendor's recent delivery record beside each one.

**Erp Objects:** Purchase Header, Purchase Line (Expected Receipt Date, Promised Receipt Date), Sales Line, Prod. Order Component, Vendor Ledger Entry

**Outcome:** Buyers start the day on the lines that need a call instead of building filters. Time on expediting triage typically falls by a meaningful fraction.

### Ask-the-ledger vendor questions

**Description:** Natural-language questions such as what did we buy from this vendor last year, at what unit cost trend, and how many lines were received late. The generated filter and fields are shown so the buyer can check.

**Erp Objects:** Item Ledger Entry, Value Entry, Purchase Receipt Line, Vendor, Item Vendor

**Outcome:** Supplier review preparation drops from a day of exports to minutes, with a visible query behind every number.

### Action message review assistant

**Description:** Reads the Planning Worksheet output, flags suggestions that conflict with vendor MOQ, lead time on the vendor card, or an existing open order that could be rescheduled instead, and proposes grouped actions for buyer approval.

**Erp Objects:** Requisition Line, Planning Worksheet, Item Vendor, Stockkeeping Unit, Purchase Line

**Outcome:** Fewer redundant new orders and fewer last-minute expedites. The buyer still carries out the plan.

### Invoice match exception triage

**Description:** Explains why a posted purchase invoice does not match the receipt, for example price variance, a partial receipt, or an unallocated item charge, and drafts the note to the vendor or buyer.

**Erp Objects:** Purch. Inv. Header, Purch. Inv. Line, Purch. Rcpt. Line, Item Charge Assignment (Purch.), Vendor Ledger Entry

**Outcome:** Accounts payable resolves exceptions with fewer back-and-forth messages. Mechanism: the cause is stated up front with the records.

### Draft purchase order from a request

**Description:** A requester describes a need, the assistant finds the item and preferred vendor, and prepares a draft purchase order in a staging area for a buyer to review before it is created through the API.

**Erp Objects:** Item, Item Vendor, Vendor, Purchase Header, Purchase Line, approval workflow

**Outcome:** Fewer mistyped item numbers and less keying. Writes are drafts, never auto-posted.

### Price and terms consistency check

**Description:** Compares price list lines, last paid cost from value entries and vendor agreement text in the document store, and flags items bought above the agreed price.

**Erp Objects:** Price List Header, Price List Line, Value Entry, Vendor payment terms, vendor contract PDFs

**Outcome:** Leakage found at review time rather than at year-end audit. The size depends on how loose control is today.

### Vendor scorecard on demand

**Description:** Computes on-time, in-full, price variance and quality reject rate per vendor and period from purchase receipts, with the ability to drill to the lines behind the rate.

**Erp Objects:** Purch. Rcpt. Header, Purch. Rcpt. Line, Purchase Line, Return Shipment records, Vendor

**Outcome:** Supplier reviews run on live numbers. Quality data from outside the ERP needs a separate connector.

## Architecture

**Overview:** The assistant never reads the Business Central database directly in SaaS. It calls supported APIs under a service identity with a permission set scoped to purchasing, and it keeps its own retrieval index for documents and history. On-premises Business Central can additionally use a read replica, but the API path is preferred so permissions and business logic are respected.

**Layers:**

#### Access layer

**Detail:** A Microsoft Entra application registered for Business Central, using OAuth 2.0 client credentials and a dedicated user with a read-focused permission set. Purchase writes use a separate, narrower identity.

#### Data connectors

**Detail:** API v2.0 for purchaseOrders, purchaseOrderLines, vendors and items, plus OData v4 web services or a small custom API page for tables not in the standard set, such as Item Vendor and posted receipts.

#### Retrieval and index

**Detail:** Documents such as vendor agreements, quality notices and supplier emails are chunked and indexed in a vector store alongside a small structured cache of vendor metrics that refreshes on a schedule.

#### Model and reasoning

**Detail:** An open-weight model such as Qwen, Llama or gpt-oss served with vLLM or Ollama in the customer tenant or on-prem, using tool calls that translate questions into filtered API requests.

#### Governance and approvals

**Detail:** Every answer shows the request and records used. Writes go to a draft queue, pass through the Business Central approval workflow where configured, and are logged with the user who approved them.

## Deployment Options

### Customer Azure tenant

**Fit:** Business Central online customers who want the model inside their own Azure subscription

**Detail:** The model runs on GPU instances in the customer's subscription and calls the BC APIs over a private endpoint where possible. Data stays within the customer's tenant and region.

### On-premises GPU server

**Fit:** Business Central on-premises or defense and regulated users who cannot send data to a hosted model

**Detail:** A local inference server next to the BC service tier. Nothing leaves the network, and the model can run with no internet access after setup.

### Light read-only pilot

**Fit:** Teams validating value before committing hardware

**Detail:** A single buyer group, a handful of APIs and a small model in a sandbox environment, with no write-back. It shows answer quality on real purchasing data in a few weeks.

## Compliance

### The assistant does not post documents. Draft orders go through the standard approval workflow, and the audit log records the requester, the approver and the model output used.

**Framework:** SOX and internal financial controls

### Vendor contact names and bank details are personal or sensitive data. Fields are excluded or masked by role, and processing stays in the region the customer chooses.

**Framework:** GDPR and vendor contact data

### For suppliers receiving controlled technical data, the model is hosted where only authorized persons have access, and controlled documents are not indexed unless the host environment qualifies.

**Framework:** ITAR and EAR export-controlled drawings

### The assistant inherits the requesting user's role. It cannot show or draft anything the user's Business Central permission set would not allow.

**Framework:** Segregation of duties

## Integration Notes

Standard API v2.0 exposes purchaseOrders, purchaseOrderLines, purchaseInvoices, vendors and items at /api/v2.0/companies({id}); use ETags on updates so edits do not overwrite a buyer's changes.

Tables not in the standard API, such as Item Vendor and posted purchase receipts, are best exposed through a small AL extension with custom API pages (APIPublisher, APIGroup, APIVersion) rather than a loose OData web service.

Use filters and $select in requests and respect the service's rate limiting, since large unfiltered pulls are throttled in SaaS and can slow other users.

Authentication is OAuth 2.0 with Microsoft Entra. Create an application registration and grant it to a Business Central user via the Microsoft Entra Applications page with a specific permission set.

Staging area for drafts: write to a custom table or to purchase documents with status Open, never to released or posted documents, and rely on the approval workflow to release.

Environment strategy: point the assistant at a sandbox environment cloned from production for testing before connecting to production.

## Product Fit

### ERPray

**Why:** Grounded natural-language answers and agents over live ERP data with the query shown, read-only by default, and respect for ERP roles.

### Custom build

**Why:** Bespoke draft-order flows, supplier scorecards joining quality and logistics data, and integrations with vendor portals or email.

## Engagement

### Scope and access

**Duration:** 1-2 weeks

**Deliverables:**

- Question inventory from buyers and AP
- Permission set and service identity design
- Sandbox environment connection
- Success measures agreed

### Read-only pilot

**Duration:** 3-4 weeks

**Deliverables:**

- Connectors for purchase, vendor and receipt data
- Late-order digest and ask-the-ledger assistant
- Accuracy test set from real questions
- Weekly review with buyers

### Draft and workflow

**Duration:** 3-5 weeks

**Deliverables:**

- Draft purchase order staging
- Approval workflow integration
- Invoice exception explanations
- Audit log and role tests

### Production and handover

**Duration:** 2-3 weeks

**Deliverables:**

- Production connection and monitoring
- Runbook and model update plan
- Training for buyers
- Backlog of next use cases

## Buyer Questions

- Which Business Central APIs and permission sets will the assistant use, and can we review them before connection?
- Can every answer show the exact filter or request and the records it used?
- Is the assistant read-only, and if it drafts orders, where do they land and who approves?
- Where does the model run, and does any vendor data go to a third-party service?
- How are Business Central extensions and custom fields in our tenant handled?
- How do you test answer accuracy against our real purchasing questions?
- What happens to the integration at each Business Central major update wave?
- When is Microsoft's own Copilot enough for us?

## Faq

### Can AI create purchase orders in Business Central?

**Answer:** It can prepare them. A typical pattern writes a draft purchase document through the API, and a buyer reviews and releases it using the standard approval workflow. Fully automatic creation and posting is possible for narrow cases such as replenishing a stable item from one vendor, but most teams keep a human on the release step because purchases commit cash and affect vendor commitments.

### Does it work with Business Central on-premises?

**Answer:** Yes. On-premises deployments expose the same API and OData endpoints from the service tier, and the model can run on a local GPU server with no outside connection. Authentication differs, using Windows or NavUserPassword or an identity provider, but the pattern of API access with scoped permissions is the same.

### Is Microsoft Copilot enough for purchasing?

**Answer:** For drafting text, summarizing a document or helping with a single page, it may be. It is less suited to cross-source questions that join purchase lines, vendor history, quality notices and contract documents, or to environments where data cannot leave a controlled network. Try the built-in features first and add a custom layer where they stop.

### How accurate are the answers?

**Answer:** Accuracy comes from grounding in your records rather than model memory. The assistant translates a question into a filtered API request and summarizes the result, and the request is shown. We test on a set of real questions before launch and track misses. Ambiguous questions should prompt a clarification, not a guess.

### Can it handle our custom fields and extensions?

**Answer:** Yes, if they are exposed. Fields added by AL extensions are not in the standard API, so we add a small custom API page that exposes them. This is routine, but it means the first phase includes a review of your extensions to decide which fields matter for purchasing questions.

### What does it cost to run?

**Answer:** The main cost is a GPU or cloud instance sized for your user count and model, plus implementation effort. A small model for a buyer group runs on a single modest GPU. Cost scales with concurrency, not with document count. A sizing exercise before purchase avoids overbuying hardware.

### Will it break when Business Central updates?

**Answer:** Standard API v2.0 is versioned and stable across updates, which is a reason to prefer it over direct database access. Custom API pages need regression checks at each major release wave. We recommend a sandbox test with the preview environment before the wave reaches production.

## Search terms

business central purchasing ai, business central purchase order ai, ai for dynamics 365 business central purchasing, business central vendor performance, business central late purchase orders, business central copilot purchasing alternative, business central api purchase orders, business central planning worksheet ai, business central three way match, on-prem ai business central

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json
