Business Central Vendor Portal: Supplier Self-Service Options

The procurement team I sat with last year had one person whose entire morning was spent doing what she called "supplier admin". Emailing vendors to ask where an order was. Forwarding invoice PDFs to accounts payable. Copying a delivery date from a reply into a spreadsheet. Answering a supplier who wanted to know when they would be paid. None of it was strategic, none of it was hard, and all of it was necessary, because there was no other channel. The suppliers had no window into Business Central, so every question and every document had to pass through a human. A vendor portal is the answer to that problem, and getting one on top of Business Central is more nuanced than most people expect, because Business Central does not ship with one. This guide walks the real options honestly, at the level of what each can actually do and what it costs you to run.

The message up front: a vendor portal for Business Central is almost never a native BC screen you switch on. It is either a Power Pages site over Dataverse, a third-party app from AppSource, or a custom application talking to the BC API. Each is a legitimate choice, and the right one depends far more on your size, your supplier count and your internal capability than on any feature checklist. Choose the operating model first, and the technology follows.

1. What a vendor portal is for (and the pain it removes)

A vendor portal is a self-service website where your suppliers log in and interact with your procurement data directly, instead of routing everything through your staff by phone and email. At its simplest it lets a vendor see their open purchase orders, confirm they can fulfil them, submit an invoice, and check when they will be paid. At its most developed it becomes a full collaboration channel covering catalogs, delivery scheduling, dispute handling and onboarding. What matters is not how elaborate it is, but which manual loops it closes.

The pain it removes is specific and measurable. Start with the inbound question load. A procurement team without a portal fields a constant stream of "where is my payment", "did you receive my invoice", "what quantity did you actually order" messages, each of which pulls someone away from real work to look up an answer that the supplier could have found themselves. A portal turns those questions into self-service lookups, and the volume that disappears is often the single most visible early win.

Then there is the document rekeying. When a supplier emails an invoice as a PDF, someone in accounts payable reads it and types the header and lines into Business Central by hand. That is slow, error-prone, and completely avoidable when the supplier submits structured data through a portal that maps straight into a purchase invoice. The same applies to order confirmations and delivery dates: a portal captures them as data at source instead of as text buried in an email thread that then has to be transcribed.

The third and least appreciated benefit is the audit trail. Email is a terrible system of record. When a delivery is disputed or a price is challenged, reconstructing what was agreed means digging through inboxes across multiple people. A portal records every confirmation, submission and status change against the transaction, with a timestamp and a user, so the history is one query instead of a forensic exercise. For teams running the wider purchasing process, this ties directly into the discipline covered in the Business Central purchasing management guide, where the order-to-invoice flow is only as clean as the data going into it.

2. What suppliers want to self-serve

Before choosing a technology it pays to be concrete about what a supplier actually wants to do without picking up the phone. In my experience the demand clusters around a handful of capabilities, and a portal that nails these covers the overwhelming majority of the value. Trying to cover everything on day one is how portal projects stall.

• See open purchase orders: the vendor wants a live list of the orders you have placed with them, with quantities, prices, expected dates and current status. This is the anchor feature. Almost everything else hangs off the ability to see the order that a conversation is about.
• Confirm and acknowledge orders: not just view an order but respond to it, confirming they can supply, proposing an alternative delivery date, or flagging a line they cannot fulfil. Capturing that response as data, rather than as a reply email, is where the workflow value starts.
• Submit invoices: the vendor wants to raise an invoice against an order or receipt and have it land in your system without emailing a PDF. Structured submission that maps to a Business Central purchase invoice removes the single biggest source of AP rekeying.
• Check payment status: "when will I be paid" is the most common supplier question in existence. Showing invoice status, approval stage, and expected or actual payment date self-service removes an enormous amount of inbound noise and improves the relationship at the same time.
• Maintain catalogs and prices: for suppliers you buy from repeatedly, letting them submit or update a price list or product catalog (subject to your approval) keeps pricing current without a manual back-and-forth every quarter.
• Provide delivery updates: shipment status, dispatch confirmation, tracking references and revised arrival dates, entered by the supplier and visible to your receiving team, so goods-in is not a surprise.

Notice the shape of this list. The first four items are about visibility and transaction flow and deliver most of the benefit. The last two are collaboration features that matter more the more strategic and repeat your supplier relationships are. A small distributor buying spot goods needs the first four. A manufacturer with a stable panel of key suppliers wants all six. Sizing the portal to your actual supplier relationships, rather than to a vendor demo, is the first real decision.

3. The reality: Business Central has no native vendor portal

Here is the fact that surprises people who assume a modern cloud ERP would include supplier self-service out of the box: Business Central does not ship a vendor portal. There is no standard screen you enable, no toggle in the setup that exposes your purchase orders to external suppliers with their own logins. Business Central is an internal system of record. It has vendor cards, purchase orders, purchase invoices and payment journals, but all of that is designed for your own licensed users working inside the application, not for external parties logging in from outside your organisation.

This is not a gap Microsoft overlooked. It reflects how the Dynamics 365 and Power Platform stack is architected. Business Central is the transactional back office. External-facing self-service is deliberately the job of a different layer, chiefly Power Pages (formerly Power Apps portals), which is Microsoft's tool for building authenticated external websites over the Dataverse data platform. The intended pattern is that external users interact with a Power Pages site, and that site is connected to Business Central rather than external users being given access to Business Central directly.

Understanding this is important because it reframes the whole project. You are not looking for a hidden feature or a configuration you have missed. You are choosing how to build an external channel that sits in front of Business Central and talks to it. That reframing also explains the licensing reality: you do not want to buy every supplier a Business Central user license, both because it is expensive and because it exposes far too much of your internal system. The portal layer exists precisely so that external users get a controlled, purpose-built surface instead of the full ERP. The way that surface connects back to BC is through its API, which is the same integration backbone described in the Business Central APIs and integrations guide.

The honest limitation: because there is no native portal, every option below is genuinely a build or a buy of a separate system that integrates with Business Central. There is no zero-integration path. Anyone who tells you a vendor portal is a quick configuration inside BC is either misunderstanding the platform or selling you something. Budget for the integration, because it is the real work in every option.

4. Option one: Power Pages on top of Business Central and Dataverse

The Microsoft-native answer is Power Pages, the low-code tool for building secure external websites within the Power Platform. In this model you build a supplier-facing site in Power Pages, external suppliers authenticate against it with their own credentials, and the data they see and submit flows between the portal, Dataverse, and Business Central. It is the option Microsoft steers you toward, and for organisations already committed to the Dynamics 365 and Power Platform ecosystem it is the most natural fit.

The strengths are real. Power Pages gives you proper external identity handling out of the box, including self-registration, invitation-based onboarding and authentication through providers like Azure AD B2C, so you are not building login security yourself. It is low-code, so a capable Power Platform maker can assemble list and detail pages, forms and dashboards without a full custom development effort. And it lives inside the same Microsoft tenant and security model as the rest of your stack, which matters for governance and for how it fits alongside the rest of your Business Central and Microsoft ecosystem.

The honest complications are equally real. The first is the data-flow architecture. Power Pages reads and writes Dataverse naturally, but your purchase orders and invoices live in Business Central, not Dataverse. So you either synchronise the relevant BC data into Dataverse (using the standard Business Central and Dataverse integration or a custom sync) so the portal reads it locally, or you have the portal call the Business Central API directly for live data. Both work, but both are integration engineering, and the choice affects latency, complexity and how fresh the supplier's view is. There is no free lunch here: the portal is only as good as the pipe connecting it to BC.

The second complication is licensing and cost. Power Pages is licensed by authenticated users or by capacity, and while it is far cheaper than giving every supplier a BC license, it is not free and the pricing model has shifted over the years, so you need current numbers for your user counts before committing. The third is that low-code still means real work. A supplier portal with order confirmation, invoice submission and payment status is a non-trivial build even in Power Pages, and it needs someone who genuinely knows the platform. It is lower effort than a fully custom app, but it is not a weekend project.

Where Power Pages fits best: mid-size to larger organisations that are already invested in the Power Platform, have or can hire Power Platform skills, and want a solution that stays inside the Microsoft governance boundary rather than introducing a third-party vendor into their supplier data flow.

5. Option two: third-party vendor-portal apps from AppSource

The second option is to buy rather than build. Microsoft AppSource, the marketplace for Dynamics 365 and Business Central extensions, hosts a number of third-party vendor and supplier portal solutions that are designed specifically to bolt onto Business Central. These range from lightweight portals focused on order and invoice visibility to broader supplier-collaboration and procurement platforms. The appeal is obvious: someone has already solved the integration problem, built the external identity handling, and packaged the common supplier workflows, so you are configuring a product rather than constructing one.

The genuine advantages of buying are speed and reduced build risk. A mature portal app has already handled the awkward parts: mapping supplier submissions to BC purchase invoices, keeping order status in sync, managing external logins, and covering the standard workflows that every procurement team needs. You get to production faster, you inherit the vendor's ongoing maintenance and feature updates, and you do not carry the full engineering burden of the integration yourself. For a team without deep Power Platform or development capability, this is frequently the pragmatic choice.

The honest caveats deserve equal weight. First, fit. A packaged product does what its designers decided a vendor portal should do, and if your process differs from their assumptions, you either change your process or pay for customisation, and customisation of a third-party app can be constrained. Second, cost model. These apps are typically subscription-priced, often per supplier or per transaction volume, and that recurring cost can grow with your supplier base in ways a one-time build does not. Third, and most important, is the data and integration question you must interrogate before signing anything.

When you evaluate an AppSource portal, the questions that actually matter are not about the feature list, which every vendor will make look complete in a demo. They are about the plumbing. How does it connect to Business Central, through the standard API or a proprietary connector? Does supplier data flow through the vendor's cloud, and if so where is it hosted and what are the data-residency and privacy implications for your suppliers' information? What happens to your portal if you later move BC environments or the app publisher discontinues the product? How are external identities managed and secured? Get straight, specific answers to those before the polished workflow screens seduce you, because the integration and the data-handling are where the risk lives, not in whether the app can show a purchase order.

The buyer's test I apply: judge an AppSource portal by its integration and its data-handling, not its feature grid. Every credible product can display an order and accept an invoice. What separates a safe choice from a risky one is how cleanly it talks to Business Central, where it stores your suppliers' data, and how gracefully you could leave it if you had to. If the vendor is vague on any of those three, treat the vagueness as the answer.

6. Option three: a custom-built portal against the BC API

The third path is to build your own portal as a custom web application that talks to Business Central through its API. Business Central exposes a comprehensive set of web services and a REST API, including standard endpoints for vendors, purchase orders, purchase invoices and much more, plus the ability to publish custom API pages for anything the standard set does not cover. A custom portal is a web application you control, authenticating your suppliers, presenting exactly the data and workflows you choose, and reading and writing Business Central through those APIs. The mechanics of that integration surface are covered in depth in the Business Central APIs and integrations guide, and this option leans on all of it.

The reason to choose this path is control and fit. When your procurement process has genuinely distinctive requirements that neither Power Pages templates nor a packaged app handle well, a custom build lets you deliver precisely the supplier experience you want, integrated exactly how you want, with no per-supplier license creep from a third party and no dependence on another vendor's roadmap. For organisations with strong internal development capability, or a trusted development partner, and a supplier collaboration model that is a real competitive differentiator, custom can be the right answer.

The reasons to be cautious are the ones every honest practitioner has to state plainly. You are now the software vendor. Everything the AppSource product gave you for free, you now own: external authentication and its security, the integration and its maintenance, the ongoing bug fixes, the adaptation when Business Central updates its API or your BC environment changes, and the whole lifecycle of a production web application exposed to the internet. That is a serious and permanent commitment, not a one-time delivery. The build cost is only the beginning; the running cost in maintenance and security is the part that outlasts the enthusiasm.

My general guidance: default away from custom unless you have a concrete reason the other two options cannot meet, and the internal capability to own a public-facing application for its whole life. Custom is the right tool for a specific and well-justified need, and an expensive mistake when chosen for the appeal of control alone. Before going down this road, it is worth being sure Business Central itself is the right long-term platform for you, which is the ground covered in is Business Central right for your organization.

7. Security and access control for external users (honest)

Whichever option you choose, the moment you expose procurement data to external suppliers you have taken on a security responsibility that internal-only ERP never carried. This is the part that gets underweighted in the excitement of the workflow features, and it is the part that will hurt most if you get it wrong. A vendor portal is, by definition, an internet-facing door into data adjacent to your ERP, and it has to be treated with the seriousness that implies.

The first principle is data isolation between suppliers. Vendor A must never, under any circumstances, be able to see Vendor B's orders, invoices, prices or payment terms. This sounds obvious, and it is exactly the kind of thing a rushed build gets subtly wrong, where a supplier can change an identifier in a URL and see another supplier's records. Whatever the technology, the access model has to enforce, on the server side, that an authenticated supplier can only ever retrieve their own data. Never trust the client to scope the query. This is the single most important control in the entire system.

The second is identity and authentication. External users need their own robust login, ideally with multi-factor authentication, proper password or passwordless policies, secure onboarding by invitation rather than open self-registration into sensitive data, and a clean offboarding path when a supplier relationship ends so their access is revoked promptly. Power Pages and mature AppSource apps give you a lot of this out of the box, which is a strong argument in their favour; a custom build means you are responsible for getting all of it right, and external authentication done badly is a breach waiting to happen.

The third is least-privilege exposure of Business Central. The portal should expose only the specific data and specific operations a supplier legitimately needs, and nothing more. It should never be a thin skin over broad BC access. This is another argument for the layered architecture Microsoft intends: external users touch the portal and its scoped data, never Business Central directly, so even a compromised supplier account cannot reach beyond the narrow surface the portal presents. Approvals and posting stay inside BC with your own staff, which connects to the controls in the Business Central approval workflows guide.

The fourth, easy to forget, is data protection and residency. Your suppliers' data, their bank details, contacts, pricing and correspondence, is personal and commercial data you are now responsible for. Where it is stored, how it is protected, who can access it, and how it complies with the data-protection regime you operate under all become your accountability the moment the portal goes live. If a third-party app routes that data through its own cloud, those questions extend to the app publisher, and you need clear answers in writing.

8. Invoice submission, e-invoicing and approval flow into BC

Of all the portal capabilities, invoice submission is where the highest return usually sits, because it attacks the most expensive manual loop: the rekeying and matching of supplier invoices in accounts payable. It is also the capability with the most moving parts, so it deserves its own careful thought rather than being treated as just another form.

The basic flow is straightforward to describe. A supplier logs into the portal, selects the purchase order or the received goods they are invoicing against, enters or confirms the line detail and totals, and submits. Instead of a PDF landing in an inbox, structured invoice data arrives ready to become a Business Central purchase invoice. The portal can validate at submission time, checking that the invoice references a real open order, that quantities do not exceed what was ordered or received, and that pricing matches the agreed terms, so many errors are caught before they ever enter your system rather than after. That validation at source is a large part of the value.

Once submitted, the invoice does not simply post itself. It should feed into the same controlled approval and matching process your own staff already run inside Business Central. This is where the portal and the ERP divide responsibilities cleanly: the supplier submits, but your organisation reviews, matches and approves. Three-way matching against the order and the receipt, exception handling for mismatches, and the approval hierarchy all stay inside BC where they belong, governed by the workflows described in the approval workflows guide. The portal feeds the front of that pipeline with clean structured data; it does not bypass the controls at the end of it.

E-invoicing is the direction this is all heading, and it is worth understanding the distinction. A portal invoice submission is a self-service convenience you provide. E-invoicing, in the regulatory sense, is the structured, standardised exchange of invoice data in a mandated format, increasingly required by tax authorities in a growing number of countries and regions. These two things overlap but are not identical: a portal can be a channel through which compliant e-invoices are received, but e-invoicing compliance brings its own format and reporting obligations that depend on the jurisdiction. If you operate where e-invoicing mandates apply or are coming, factor those requirements into the portal decision, because a portal that captures invoice data in a structured way is a natural foundation for meeting them, whereas one that just accepts PDFs is not.

There is also an increasingly practical middle path worth naming: rather than requiring every supplier to use a portal, you can let suppliers keep emailing invoices and use AI-based document processing to extract the structured data automatically before it reaches BC. That does not replace a portal, but for a long tail of low-volume suppliers who will never adopt a portal, it closes much of the same rekeying gap, as explored in the AI invoice document processing for Business Central guide. In practice many organisations end up combining both: a portal for the strategic suppliers who transact often, and AI extraction for the occasional ones who never will.

9. Build versus buy: choosing the right option for your size

Stripped of the technology detail, the decision comes down to matching the option to your organisation honestly, and the biggest driver is not features, it is your size, your supplier count and your internal capability. I would frame it as three broad profiles.

Smaller organisations with modest supplier collaboration needs. If you have a manageable number of suppliers and the pain is mostly invoice rekeying and payment-status questions, a packaged AppSource portal is usually the sensible choice, or in some cases you may find that AI-based invoice extraction plus disciplined email is enough and you do not need a full portal at all. The instinct to build custom at this size is almost always a mistake, because you do not have the volume to justify owning a public application and its lifetime of maintenance. Buy the capability, keep it simple, and spend your energy on the process rather than the software.

Mid-size organisations already in the Microsoft ecosystem. If you have a meaningful supplier base, some Power Platform capability or the willingness to acquire it, and you value staying inside the Microsoft governance boundary, Power Pages is the strong candidate. You get Microsoft-native identity and security, low-code build speed, and a solution that fits your existing stack, at the cost of doing the Business Central data-integration work properly. This is the sweet spot where the Microsoft-native path genuinely shines, provided you respect that the integration is real engineering and resource it accordingly.

Larger organisations with distinctive requirements and real development capability. If supplier collaboration is strategically important, your process is genuinely non-standard, and you have the internal or partner capability to own a production application for its full life, a custom build against the BC API gives you the control and fit that neither packaged apps nor low-code templates can match. But enter this path with your eyes open to the permanent ownership it implies, and only when a specific, articulated need justifies it. Choosing custom for the feeling of control, without the capability to sustain it, is the most expensive of the three mistakes.

Across all three, the same discipline applies: define the small set of capabilities that remove your actual pain, size the solution to your real supplier relationships rather than to a vendor's aspirational demo, and weigh the running cost, not just the build cost, because a portal is a system you operate for years, not a project you finish once.

10. A practical path to launching supplier self-service

However you decide to build it, the sequence of getting a vendor portal live matters as much as the technology choice. The pattern that works is deliberately incremental, because a portal that tries to launch fully featured to all suppliers at once tends to launch late, if at all.

• Step 1: name the pain precisely. Before evaluating any option, quantify what you are actually trying to fix. Count the supplier-admin hours, the invoice rekeying volume, the payment-status queries. That number is what justifies the investment and what you will measure against later. Skip this and you cannot tell whether the portal worked.
• Step 2: choose the operating model, then the technology. Decide build versus buy based on your size, supplier count and capability, using the profiles above. Let that decision drive the technology, not the other way around. The most common error is falling in love with a product demo before deciding whether buying is even the right model for you.
• Step 3: start with visibility and one transaction. Launch with order visibility and invoice submission for a small pilot group of cooperative suppliers. Prove that the data flows cleanly into Business Central and back, that the isolation between suppliers holds, and that the approval process on your side stays intact. Do not add catalogs, delivery scheduling and dispute handling until the core loop is solid.
• Step 4: onboard suppliers deliberately. A portal only pays off if suppliers actually use it. Onboard in waves, starting with your highest-volume suppliers where the payoff is largest, support them through the change, and make the portal genuinely easier for them than email or they will quietly keep emailing. Supplier adoption, not software features, is what determines success.
• Step 5: keep a fallback for the long tail. Accept that some low-volume suppliers will never adopt a portal, and plan for them rather than fighting it. AI-based invoice extraction from email is a practical fallback that captures much of the same benefit for suppliers who will not log in.
• Step 6: measure against the baseline and expand. Come back to the Step 1 numbers. Did supplier-admin hours fall? Did rekeying errors drop? Did payment-status queries decline? Expand the feature set and the supplier base only where the measured return justifies it. Deliberate, evidence-led expansion beats a big-bang rollout every time.

The thread running through all six steps is restraint. The portals that succeed are the ones that removed a clearly defined pain for a clearly defined group of suppliers, proved the loop, and grew from there. The ones that struggle are the ones that tried to build the complete supplier-collaboration vision in one release, for every supplier, before proving that a single invoice could flow cleanly from a supplier into Business Central and back out as a payment status.

Final thoughts

A vendor portal for Business Central is not a feature you switch on, it is a system you choose, build or buy, and then operate for years. Business Central deliberately keeps external self-service in a separate layer, so every real option, Power Pages over Dataverse, a third-party AppSource app, or a custom application against the BC API, is genuinely a piece of integration engineering sitting in front of your ERP. That is not a problem to be solved away; it is the nature of the work, and pretending otherwise is how projects go over budget.

The practitioner's judgement that matters most is the build-versus-buy call, and it is driven less by features than by who you are: your size, your supplier count, and your capability to own what you build. Smaller teams should almost always buy or lean on AI extraction. Mid-size Microsoft-committed organisations should look hard at Power Pages. Only larger organisations with distinctive needs and real development muscle should custom-build, and only with clear eyes about the permanent ownership it brings. Get that call right, respect the security responsibility that comes with opening a door to external suppliers, start small and measure honestly, and a vendor portal will quietly remove one of the most tedious and least valuable workloads your procurement team carries. That is worth doing well, and it is entirely doable, as long as you choose the operating model before the technology and never let a polished demo make the decision for you.

Related reading: Business Central purchasing management, Business Central APIs and integrations, Business Central approval workflows, AI invoice document processing for Business Central, Business Central and the Microsoft ecosystem, Is Business Central right for your organization.