How to Build a Customer Portal Connected to Your Business System

Your customers are emailing your sales team asking for order status. Your accounts team is printing invoices and posting them. Your customer service desk spends two hours every morning responding to “where is my order?” queries.

This is not your team’s fault. It is the direct consequence of running an ERP that was never designed to share data with customers. Business systems like Dynamics 365 Business Central, Sage 200, and OrderWise are built for internal operations — not for external self-service.

A customer portal changes that. It connects directly to your ERP and exposes the specific data your customers need: orders, invoices, stock availability, pricing, delivery tracking. Your customers get what they want instantly. Your team stops acting as a manual data relay.

This guide walks through every step of building a customer portal connected to your business system: how to plan it, how to build it, how to secure it, and how to get your customers to actually use it.

Why a Customer Portal Is a Strategic Investment

Before we get into the how, let us be clear on the why. A customer portal is not merely a nice-to-have digital extra. For wholesale distributors and manufacturers, it is becoming a competitive necessity.

Consider what happens every time a customer needs information that lives in your ERP:

• A customer emails “has my order shipped?” → your team opens the ERP → finds the order → types a reply. Average time: 4–6 minutes per query.
• A customer calls to ask about stock on a SKU → your team pauses what they are doing → checks the system → reads the number. Average disruption: 3–5 minutes per call.
• A customer wants a copy of an invoice from two months ago → your accounts team searches through the system → exports to PDF → emails it. Average time: 8–12 minutes.

For a business with 200 active customers, each contacting you four times per month, that is 40–80 hours of staff time every month spent on data retrieval tasks that a portal handles in zero staff time.

The ROI case is straightforward: a customer portal typically pays for itself within six to twelve months through reduced customer service overhead alone. The indirect benefits — faster order placement, fewer errors, higher customer retention — amplify the return further.

Research backs this up. McKinsey reports that B2B companies with mature digital self-service capabilities see 30–50% lower service costs and 10–20% higher customer satisfaction scores. For UK manufacturing and distribution SMEs, the numbers are similar: businesses that deploy customer portals report an average 25% reduction in order-related phone calls and a measurable improvement in on-time payments due to easier invoice access.

Step 1: Define Scope — What Features, Which Customers, Read-Only or Ordering?

The single biggest mistake in portal projects is trying to do everything at once. A portal that attempts to replicate your entire ERP for every customer is a portal that never ships.

Start by answering three questions:

Which customers get access first?

Do not give every customer access on day one. Identify a pilot group — typically your top 10–20 customers by revenue, or the ones who place the most frequent small orders. These customers generate the highest volume of queries, so they will deliver the fastest ROI. They are also the most likely to tolerate early-stage rough edges and provide useful feedback.

Your remaining customers can be onboarded in waves. This phased approach lets you iron out problems before the portal reaches customers who are less forgiving.

Read-only or transactional?

This is the most consequential architectural decision you will make.

Read-only portals let customers view orders, invoices, statements, stock levels, and delivery status. Data flows one way: from your ERP to the portal. Read-only is simpler to build, carries less security risk, and does not require you to handle write-back conflicts or validation errors from your ERP.

Transactional portals let customers place orders, request quotes, raise returns, update delivery addresses, and make payments. Data flows both ways. Transactional portals deliver greater value but require careful handling of pricing, credit limits, stock allocation, and order validation.

Our recommendation: start read-only. Launch a portal that lets customers view their information. Once that is stable and adopted, add transactional features in a later phase.

What features do you include?

Build a prioritised feature backlog. Start with the top five features that will eliminate the most queries to your team. For most distributors, that list looks like this:

1. Order status and history
2. Invoice and statement download
3. Live stock availability
4. Account balance and credit limit
5. Delivery tracking

Add features like quote requests, returns, address management, and reordering once the foundation is solid. A well-defined scope is the difference between a project that ships in eight weeks and one that drags on for eight months.

Step 2: Audit Your Business System’s API

Your portal needs data. That data lives in your ERP. Before you can design anything, you need to know what your business system will let you access.

Every modern ERP exposes data through an API — a set of programmatic endpoints that let external applications read and write data. But the quality, breadth, and performance of these APIs vary enormously.

What to audit

Endpoint coverage. Can the API expose sales orders, invoices, customers, items, stock levels, and delivery status? For each entity, note whether it supports read, write, or both. Many ERPs expose invoices as read-only (and rightly so for audit purposes), but stock availability and sales orders should be readable.

Authentication model. Does the API support OAuth 2.0? Does it support service-to-service authentication (client credentials flow) for automated access? Or does it require a user credential for every API call? The authentication model determines how you architect your security layer.

Rate limits and performance. How many API calls can you make per minute? What is the average response time for a single order query versus a list query? Some ERPs throttle aggressively, which affects how you design caching and page loads.

Data filtering. Can you filter orders by customer account number? Can you request only orders from the last 30 days? Server-side filtering is essential for building a performant portal, especially for customers with large transaction histories.

ERP-specific considerations

Dynamics 365 Business Central exposes a comprehensive REST API v2.0 with OData query support. Standard endpoints cover sales orders, invoices, customers, items, and item availability. Custom API pages can be created in AL for any custom business logic. Authentication is via OAuth 2.0 / Microsoft Entra ID.

Sage 200 offers a SOAP-based API and a newer REST API. Coverage is good for core entities but some custom fields and workflows may require additional development. Authentication uses API keys or OAuth depending on the version.

OrderWise provides a REST API with coverage for orders, stock, customers, and deliveries. The API is functional but can have performance limitations under heavy query loads, making caching particularly important.

Kerridge K8 (now Epicor K8) exposes a REST API with reasonable coverage for order processing, stock, and customer data. Some operations require specific endpoint design due to K8’s architecture.

A thorough API audit in week one prevents nasty surprises in week eight. If your ERP does not expose the data you need through its API, you have two options: build a custom API endpoint within the ERP (possible in BC via AL API pages, and in Sage via an add-on), or consider an alternative integration approach.

Step 3: Design the Portal — Customer UX, Account-Scoped Data, Branding

Your customers are not your employees. They do not want to learn your ERP’s terminology. They do not want role centres, fact boxes, or navigation panes designed for accountants. They want a clean, task-focused experience that answers their specific questions.

Account-scoped data

Every customer must see only their own data. This sounds obvious, but it is the hardest thing to get right in practice. When a customer logs into the portal, the system must know which customer account they belong to and filter every single data query by that account identifier.

This means:

• Orders are filtered by customer account number
• Invoices are filtered by customer account number
• Stock visibility may be filtered by customer-specific pricing
• Statements are generated for that customer only

The filtering must happen server-side, not client-side. You cannot load all orders into the browser and then filter them with JavaScript — that is a data breach waiting to happen. Every API call from the portal to your ERP must include the customer identifier as a query parameter, and your API adapter must enforce that filter.

Customer experience design

Design for the three most common tasks your customers perform:

1. Checking order status: A dashboard showing recent orders with clear visual status indicators (confirmed, picked, shipped, delivered). Each order links to a detailed view with line items, carrier tracking, and estimated delivery dates.
2. Finding invoices: A searchable, filterable list of invoices with one-click PDF download. Include statement view for outstanding balances.
3. Checking stock and pricing: A product search that returns live stock availability and the customer’s specific pricing. No login should be required for this if you want to support guest browsing, but pricing must be account-specific.

Branding

The portal should look like your brand, not your ERP vendor’s. Use your logo, your colours, your typography. The portal URL should be on your domain (‘portal.yourcompany.com’). Every page should reinforce that this is your service — not a third-party tool your customers have been sent to.

White-labelling also builds trust. Customers are more likely to enter login credentials on a portal that looks like the company they already do business with.

Step 4: Build the Architecture — API Adapter Layer

This is where the technical work happens. The architecture of a customer portal follows a consistent pattern regardless of which ERP you are connecting to.

Your ERP System (BC / Sage 200 / OrderWise / K8)
         │
         │ REST / SOAP API (HTTPS)
         │ OAuth 2.0 / API Key
         ▼
API Adapter Layer (Node.js / TypeScript)
  · ERP client (auto-generated per platform)
  · Request/response transformation
  · Data caching layer (Redis / in-memory)
  · Rate-limit management
  · Idempotency for write operations
         │
         ▼
Application Layer (Next.js / React)
  · Server-side rendering
  · React Server Components
  · Customer-scoped data isolation
         │
         ▼
Customer Portal (Branded UI)
  · Order tracking
  · Invoice access
  · Stock & pricing
  · Account management

Why an API adapter layer matters

The adapter layer is the single most important architectural decision. It isolates your ERP integration in one place. Here is why that matters:

• ERP versioning: If your ERP vendor updates their API, you update the adapter. The frontend application does not change.
• ERP migration: If you ever switch ERP systems, you rewrite the adapter. The portal your customers use stays exactly the same.
• Multi-ERP: If you run multiple systems (BC for finance, a separate WMS for warehousing), the adapter can aggregate data from both and present a unified view.
• Caching: The adapter is the natural place to add caching. Frequently requested data like stock levels or pricing can be cached with short TTLs (30–60 seconds) to reduce load on your ERP’s API.

Authentication architecture

The portal uses two separate authentication flows:

1. Customer authentication: Customers log into the portal using secure credentials (email + password, or OAuth 2.0 with their own identity provider). This gate controls which customer account they belong to.
2. System-to-system authentication: The portal’s backend authenticates to your ERP using service credentials (OAuth 2.0 client credentials or API key). This is the connection that reads and writes data on behalf of the logged-in customer.

The two flows must never be confused. The customer’s identity determines which data they can see. The service credential determines how the system connects to the ERP. The adapter layer enforces the mapping between the two: a customer logged in as account ABC123 can only query orders where SoldToCustomerNumber equals ABC123.

Caching strategy

Your ERP was not designed to serve as a real-time API for a customer portal. Its database is optimised for transactional processing, not for handling hundreds of concurrent API queries from an external web application. Caching protects your ERP from excessive load.

Good caching rules of thumb:

• Stock levels: cache for 30–60 seconds (stale stock is better than a crashed ERP)
• Order status: cache for 60–120 seconds (orders do not change every second)
• Invoices: cache for 5–15 minutes (invoices change rarely)
• Customer details: cache for 1–24 hours (customer details are relatively static)
• Product catalogue: cache for 1–24 hours (products change infrequently)

Use a distributed cache like Redis for multi-instance deployments, or in-memory caching for simpler single-server setups. Invalidating the cache on write operations (e.g. after a customer places an order) keeps data fresh without aggressive TTLs.

Step 5: Connect to Your ERP Platform

Each ERP platform has its own quirks. Here is what to watch for with the most common UK business systems.

Dynamics 365 Business Central

BC’s REST API v2.0 is the strongest of the group. It supports OData query options ($filter, $select, $expand) which makes it straightforward to build filtered queries for customer-scoped data. The OAuth 2.0 integration with Microsoft Entra ID is mature and well-documented.

Key consideration: BC API page customisation. If the standard API does not expose a piece of data you need (e.g. a custom field on the sales order header), you can create an API page in AL that exposes exactly that data. This requires AL development expertise but is a clean, supported approach.

Sage 200

Sage 200’s API landscape is more fragmented. Older versions use a SOAP-based API which is functional but verbose. Newer versions offer a REST API, but coverage varies by module. The Sage 200 API authenticates via API keys, which are simpler to set up than OAuth but offer less granular control.

Key consideration: Sage 200’s stock availability endpoint can be slow under load because it calculates real-time available quantities across multiple warehouses. Aggressive caching is essential.

OrderWise

OrderWise offers a REST API that covers the major entities. The API is pragmatic but performance can degrade with complex queries. OrderWise’s data model is highly normalised, so retrieving a single order with line items, stock allocations, and delivery status may require multiple API calls.

Key consideration: OrderWise rate limits are more restrictive than other platforms. Design your adapter to batch requests and respect rate-limit headers.

Kerridge K8 (Epicor K8)

K8’s REST API covers order processing, stock, and customer data. The API uses OAuth 2.0 authentication. K8’s pricing engine is complex, so if you are exposing customer-specific pricing in the portal, test thoroughly with different customer groups and discount structures.

Key consideration: K8’s API endpoint structure can differ between on-premise and cloud-hosted instances. Confirm which deployment model you are targeting before development begins.

Step 6: Security — OAuth 2.0, Entra ID, Account Isolation, UK Data Residency

A customer portal exposes your ERP data to the internet. Security is not optional — it is foundational.

Authentication: OAuth 2.0 and Entra ID

Use a recognised authentication framework. OAuth 2.0 is the industry standard for web application authentication and authorisation. If your customers already have Microsoft 365 accounts (e.g. they are also users of your ERP as suppliers), you can use Microsoft Entra ID as the identity provider for seamless SSO.

For customers without Microsoft accounts, use a standards-based authentication provider (Auth0, AWS Cognito, or similar) that supports OAuth 2.0, multifactor authentication, and password policies compliant with NCSC guidelines.

Account isolation (multi-tenancy)

This is the most critical security control. Every customer must be isolated at every layer of the stack:

• Session layer: The customer’s session token contains their internal account identifier. This identifier is signed server-side and cannot be tampered with.
• Application layer: Every API route checks the session token and extracts the customer identifier before querying data.
• Adapter layer: Every query to the ERP includes the customer identifier as a filter parameter.
• Database layer: If you cache any data, it is tagged by customer identifier and cannot be accessed without the correct identifier.

Penetration test this specifically: attempt to access another customer’s data by manipulating URL parameters, session tokens, and API request bodies. Account isolation failures are the most common vulnerability in customer portals.

UK data residency

If your customers are UK-based, their data should stay in the UK. Host your portal infrastructure in UK-region cloud (Azure UK South, AWS London, or a UK-based provider). Ensure your authentication provider and any third-party services also store data in the UK or a jurisdiction with adequate data protection agreements.

Your data processing agreement should name the UK as the primary data storage location. Review your ERP vendor’s data residency options — if your ERP is hosted in a different region, the API traffic crosses borders, which has implications under UK GDPR.

Additional security measures

• HTTPS everywhere (TLS 1.2 minimum, TLS 1.3 recommended)
• Rate limiting per customer account (prevent brute-force attacks)
• Session timeout after 15–30 minutes of inactivity
• Audit logging of all data access by customer and timestamp
• Web Application Firewall (WAF) in front of the portal
• Regular penetration testing (minimum annually, quarterly recommended)

Step 7: Test and Launch — Customer Pilot, UAT, Soft Launch

Your portal is built. Now you need to get it in front of real customers — carefully.

Internal testing

Before any customer sees the portal, your own team should test it thoroughly. Create test customer accounts with realistic data. Run through every workflow. Test error states: what happens when the ERP API is down? What happens when a customer’s account is on credit hold? What happens when an invoice PDF fails to generate?

Test on mobile devices. A surprising percentage of B2B portal traffic comes from mobile phones — warehouse managers checking stock on the shop floor, business owners reviewing orders from home. The portal must be fully responsive.

Customer pilot (closed beta)

Select 3–5 friendly customers for a closed pilot. These should be customers who understand they are using early-stage software and will provide constructive feedback. Give them direct access to your product team via a shared channel (Slack, Teams, or WhatsApp).

Run the pilot for two to four weeks. Track every issue, every confusing UI element, every slow page load. Prioritise fixes based on frequency and severity. Do not add new features during the pilot — stabilise what you have built.

User acceptance testing (UAT)

After the pilot, expand to a wider group (15–30 customers). Provide structured UAT scripts that guide customers through each feature. Collect quantitative data (task completion rates, page load times, error rates) alongside qualitative feedback.

UAT is also the time to validate your onboarding process. Can a customer register and log in without calling your support team? If not, fix the onboarding flow before the full launch.

Soft launch

Open the portal to all customers but do not make it mandatory. Send a launch email with clear instructions, a link to a short video tutorial, and contact details for support. Monitor usage metrics closely for the first two weeks. Respond to every support request within four hours during this period.

A soft launch lets you catch edge cases you missed in testing without the pressure of a hard deadline. Plan for two to four weeks of soft launch before you begin actively retiring manual processes.

Step 8: Drive Adoption — Onboarding, Training Materials, Support

Building the portal is only half the battle. Getting customers to actually use it is where most projects succeed or fail.

Customer onboarding

Make the first login as frictionless as possible. Send each customer a personalised onboarding email with:

• Their unique portal URL
• A temporary password or magic-link login
• A 90-second video showing the three most common tasks
• A PDF quick-reference guide
• Contact details for portal support

Follow up with a phone call from their account manager one week later. The personal touch from someone they already know drives far higher adoption than automated emails.

Training materials

Create a simple help centre (a single page is fine initially) covering:

• How to log in and reset your password
• How to check order status
• How to view and download invoices
• How to check stock and pricing
• How to place an order (if applicable)

Short screen-recorded videos (90–120 seconds each) are more effective than written guides. Host them on the portal itself or on YouTube as unlisted videos linked from the portal.

Internal adoption

Your own team needs to change how they work too. If a customer emails asking for order status, the response should be “You can check this anytime on your portal — here is the link.” Not “Let me look that up for you.”

This requires a deliberate behaviour change. Brief your customer service team. Give them scripted responses. Track the number of queries that are redirected to the portal versus answered directly. Incentivise the team to redirect rather than answer.

Measuring adoption

Track these metrics from day one:

• Percentage of active customers who have logged in at least once
• Percentage of logins that result in a completed task (order check, invoice download, etc.)
• Reduction in phone and email queries for portal-covered data
• Net Promoter Score (NPS) for the portal experience

Set a target: 60% active adoption within three months, 80% within six months. If you are below 40% at three months, investigate why. Common blockers include poor onboarding, missing features that customers actually need, or a login process that is too cumbersome.

Typical Features Checklist

Here is a comprehensive checklist of features you might include in your customer portal. Use it to scope your project and prioritise your roadmap.

Frequently Asked Questions

1. How long does it take to build a customer portal?

A read-only customer portal connected to an ERP typically takes 6–12 weeks to build. A transactional portal with order placement and payment can take 10–16 weeks. The timeline depends on API complexity, feature scope, and whether the ERP requires custom API development. A discovery sprint (3–5 days) can give you an accurate timeline for your specific situation.

2. Do I need to modify my ERP to build a portal?

Not necessarily. Most modern ERPs expose sufficient data through their standard APIs for a read-only portal. If you need transactional features or data from custom fields, you may need to create custom API endpoints (e.g. API pages in Business Central AL, or a custom web service in Sage). The portal itself does not require any modifications to the ERP database or schema.

3. Can I build a portal if my ERP is on-premise?

Yes, but the architecture differs. An on-premise ERP requires either a publicly exposed API endpoint (with appropriate security controls) or a secure tunnel between your cloud-hosted portal and your on-premise network (via VPN or a secure agent). This adds complexity but is a well-understood pattern with established solutions.

4. What happens to the portal if I change my ERP?

If the portal has a well-designed API adapter layer, only the adapter needs rewriting when you change ERP systems. The customer-facing frontend stays the same. This is one of the strongest arguments for investing in a custom portal over a pre-built solution tied to a specific ERP platform.

5. How do I handle customers who refuse to use the portal?

Start by understanding why. Common reasons include: the portal is missing a feature they rely on, the login process is too slow, or they simply prefer the personal contact. Address the underlying issue where possible. For customers who genuinely prefer phone or email, consider a phased transition — introduce a small surcharge for manual order processing or offer a discount for portal orders. Most customers switch once they see how much faster the portal is.

6. What ongoing maintenance does a customer portal require?

Ongoing maintenance includes security patching (OS, framework, dependencies), monitoring and alerting, API compatibility updates when your ERP vendor releases a new version, feature updates based on customer feedback, and periodic penetration testing. Budget for 5–10 hours per month of maintenance for a stable portal, and more during feature development phases.

---