The Complete Guide to ERP-Connected Customer Portals for UK Manufacturers

What Is an ERP-Connected Customer Portal?

A customer portal is a secure web application that gives your customers 24/7 access to their data from your business system — orders, invoices, stock, account status — without needing to phone or email your team. When that portal is connected directly to your ERP, the data is live. It is not a daily export or a manually updated spreadsheet. It is the same information your staff see, served to your customers in real time through a branded, easy-to-use interface.

Think of it as your ERP’s front door for customers. Your business system holds all the data your customers might ask about: has my order shipped? When will it arrive? Can I see the invoice? What is my credit limit? Is that part in stock? A self-service portal puts those answers directly in your customers’ hands, cutting your team out of the middle of every single inquiry.

For UK manufacturers specifically, a B2B portal is not the same as the consumer-style account portals you see from retailers. A dealer portal for a manufacturing business must handle trade-specific complexity: account-level pricing, credit terms, minimum order quantities, delivery schedules, batch and serial number tracking, proof-of-delivery documents, and certificate of conformity retrieval. It is a serious piece of business software, and it needs to be engineered to the same standard as your ERP.

Why UK Manufacturers Need One

Here is the problem most UK manufacturers do not measure: how much of your sales team’s day is spent answering questions your ERP already knows the answer to?

“When is my order shipping?” — the ERP knows. “Can you send me the invoice again?” — the ERP has it. “How much stock do you have of X?” — the ERP can tell you in real time. Every single one of those questions triggers a phone call or an email, which your salesperson must interrupt their work to handle. They navigate through BC’s or Sage’s or OrderWise’s interface, find the answer, and relay it. A two-minute interaction. Twenty to thirty times a day. That is an hour or more of skilled sales time lost to data retrieval.

The numbers are well established. Companies that deploy a customer-facing portal connected to their ERP typically see a 40–60% reduction in order-status phone calls. Some report as high as 75% when the portal includes live carrier tracking and document download. That is not just a cost saving — it is your sales team getting back hours of productive time each week.

Beyond call reduction, the competitive pressure is mounting. Your customers increasingly expect the same digital experience from their suppliers that they get from Amazon and DHL. If they can track a parcel to the driver’s location in real time, they find it baffling that they need to telephone someone to find out where their £50,000 machine part order is. A web portal meeting that expectation is becoming a requirement to win and retain business, especially with larger customers and Tier 1 suppliers who audit your digital capabilities as part of their vendor assessment.

There are other drivers too. Late payment is a persistent issue in UK manufacturing. When customers cannot easily find, view, or download their invoices, payments slow down. A customer hub that surfaces invoices, statements, and credit notes on demand helps reduce the “I never received the invoice” cycle that stretches payment terms. Manufacturers who deploy online self-service for invoices report average payment cycles reducing by 7–12 days.

Finally, there is the question of accuracy. Every piece of information relayed through a human introduces error risk. The stock figure was correct this morning but is now stale. The order status was updated an hour ago but the salesperson has not refreshed their screen. A digital portal connected directly to your ERP eliminates those information gaps. The customer sees exactly what the system says, exactly when it says it.

How It Works: The Architecture

An ERP-connected client portal is not a separate system with its own database. It is a thin application layer that reads and writes data through your ERP’s API in real time. Here is the architecture at a glance:

Your ERP System (BC / Sage 200 / OrderWise / Kerridge / SAP B1)
         │
         │  REST API (OData / JSON) — read + write
         │  OAuth 2.0 / API Key authentication
         ▼
API Adapter Layer (isolated)
  · ERP-specific API client (auto-generated)
  · Request/response mapping & transformation
  · Caching layer (Redis, configurable TTL)
  · Idempotency for write operations
  · Rate limiting & retry logic
  · Field-level data filtering (customer A sees only customer A’s data)
         │
         ▼
Application Layer (Next.js / React)
  · Server-side rendering for performance
  · Secure session management
  · Role-based access control
         │
         ▼
Customer Portal (web + mobile-responsive)
  · Order tracking & history
  · Invoice & document download
  · Live stock availability
  · Account management
  · Reordering from history
  · Communication & notifications

The adapter pattern is the critical piece. The API adapter layer sits between your ERP and the portal application. It translates the ERP’s native API into a consistent, portal-optimised interface. If your ERP’s API changes (a new version, a deprecated endpoint), you update only the adapter — not the entire portal. If you ever change your ERP, you swap the adapter for a new one while the portal frontend stays the same. This separation of concerns is what makes a portal solution both maintainable and future-proof.

Data flow is real time. When a customer logs into their online account and checks order status, the portal makes an API call to your ERP, fetches the current state, and renders it. There is no batch sync, no overnight data load, no stale copy. The stock figure they see is the stock figure in your warehouse right now. This is different from older portal technologies that relied on database replication or nightly extracts, which were always behind and created reconciliation headaches.

Authentication works through your existing identity model. Staff from your organisation can authenticate via your existing Microsoft Entra ID / Azure AD single sign-on. External customers authenticate through a separate mechanism — typically email-and-password with multi-factor authentication, or a token-based invitation flow managed through the ERP’s customer record. No customer ever sees another customer’s data. The adapter layer enforces field-level filtering using the ERP’s own customer security model.

Core Features

A properly built external portal delivers a specific set of capabilities. Here is what you should expect, whether you build or buy:

Not every manufacturer needs every feature from day one. A phased approach is common: start with order tracking and invoice download (the highest-volume customer queries), add stock visibility and reordering in phase two, then layer on documents and communication in phase three. Spread the investment. Validate adoption at each stage.

Portal Approaches Compared

There are three main routes to getting an ERP-connected customer hub. Each has trade-offs in cost, timeline, flexibility, and control.

The right choice depends on your specific circumstances. If you run a standard, vanilla Business Central instance with no customisations and need a basic trade portal quickly, an ISV add-on may be sufficient. If you are already deep in the Microsoft Power Platform ecosystem and your requirements are simple, Power Pages can work. If you have complex pricing, multiple ERP systems, unique workflows, or specific branding and UX requirements, a custom-built portal solution is the only way to get exactly what you need.

What It Costs

Pricing for portal software varies enormously depending on approach, scope, and the number of customers you serve. Here are realistic ranges for a UK manufacturer with 50–200 active portal users.

A few things to note about these numbers. ISV add-on costs vary enormously by ERP platform and vendor. Some charge per user, others per company, others as a percentage of your ERP licence fee. Always ask for a full pricing schedule including implementation, training, and support. Power Pages costs depend heavily on authentication type (anonymous vs authenticated), page views, and data storage — the figures above assume authenticated external users with moderate usage. Custom-built costs depend on scope: a read-only order tracking portal is at the lower end; a full portal with write-back, stock visibility, document management, and complex pricing is at the higher end.

The custom-built approach has an important cost advantage over time: you own the intellectual property. After the build is complete and the minimum term is served, you can take the portal software elsewhere, bring it in-house, or stop entirely. There is no perpetual licence fee. ISV add-ons charge you every year indefinitely, and if you stop paying, you lose access.

How to Build One

Building a customer-facing portal connected to your ERP is a structured process. Here is how we approach it at Sysgraft, which maps to any serious portal project:

Step 1: Discovery (3–5 days)

Before writing any code, understand what your customers actually need. Review support tickets and call logs to identify the top 10 questions your team answers daily. Conduct stakeholder interviews with sales, customer service, finance, and warehouse. Map the customer journey from order placement to delivery to payment. Identify the workflows that create the most friction for both your team and your customers.

Step 2: API Audit (1–2 days)

Authenticate against your live ERP tenant and enumerate every available API endpoint. Test read operations against real data. Validate write-back against your business logic. Identify gaps where the standard API does not cover what you need. For many modern ERPs (Business Central, Sage 200, OrderWise, Kerridge, SAP B1), the standard API covers 80–90% of common portal use cases. For the remainder, you may need custom API pages or endpoints exposed by your ERP partner.

Step 3: Design (1–2 weeks)

Wireframe the portal’s information architecture: what does the customer see when they log in? How do they find an order? How do they download an invoice? How do they check stock? Design the user experience for clarity, not feature count. A good B2B portal is ruthlessly focused on the tasks customers perform most often. Prototype and test with real customers if possible.

Step 4: Build with Adapter Pattern (4–8 weeks)

Build the API adapter layer first. This is the foundation. Once it is tested against your live ERP, build the portal application on top. Use a modern tech stack: React or Next.js for the frontend, TypeScript for type safety, server-side rendering for performance. Weekly sprint cycles with working software at the end of every week. No scope creep — the build is against the scope defined in discovery and design.

Step 5: Test (1–2 weeks)

Test with a pilot group of customers before full launch. Real users, real data, real workflows. Collect feedback, fix issues, refine the UX. Test for edge cases: what happens when the ERP is offline? When an API call times out? When a customer tries to order more than their credit limit? A robust portal handles every failure state gracefully.

Step 6: Launch and Iterate (ongoing)

Launch to your full customer base. Measure adoption, call volume changes, and user satisfaction. Plan phase two with the features your pilot group most requested. A portal is never “finished” — it evolves as your customers’ expectations and your business needs change.

ERP-Specific Considerations

The specifics of building a B2B portal vary depending on which ERP you run. Here is what changes per platform:

Dynamics 365 Business Central

BC has the richest out-of-the-box REST API of any ERP in this list. API v2.0 covers sales orders, invoices, items, customers, stock availability, and more. Authentication is via OAuth 2.0 with Microsoft Entra ID. The API is well documented and Microsoft releases six updates per year with versioned endpoints. If you need an endpoint not in the standard API, BC supports custom API pages written in AL. Read more about BC customer portals.

Sage 200

Sage 200 exposes both a REST API and an older SOAP API. The REST API is more limited than BC’s, particularly around stock availability and write-back capabilities. Many Sage 200 portal projects require custom API development or a middleware layer to fill the gaps. Sage’s API authentication uses API keys rather than OAuth, which is simpler but less granular for field-level security. Sage 200 on-premise installations may require a gateway or bridge to expose the API securely to the internet.

OrderWise

OrderWise provides a comprehensive REST API covering orders, stock, customers, invoices, and despatch. The API is well-suited to trade portal use cases. OrderWise supports real-time stock queries and order write-back, making it one of the stronger platforms for self-service portal builds. Authentication is via API key. The main consideration with OrderWise is understanding which version of their API your instance is running, as they have made significant version changes.

Kerridge K8

Kerridge (now Epicor K8) serves a significant portion of UK automotive parts and building supplies distributors. Its API coverage is solid for order processing and stock enquiries, but write-back capabilities vary by module. Kerridge environments often have complex pricing models (matrix pricing, customer-specific discounts, promotion periods) that need careful mapping in the portal adapter. Authentication is typically via username/password tokens or IP whitelisting.

SAP Business One

SAP B1 exposes the Service Layer REST API, which covers the full suite of B1 objects including orders, deliveries, invoices, items, and business partners. The API is well documented and supports OAuth 2.0. B1’s particular complexity lies in its pricing engine (price lists, volume discounts, special pricing agreements) and its warehouse management model. These translate well to a portal but require careful adapter engineering to ensure the customer sees accurate, real-time pricing.

ROI and Payback

The business case for a customer portal software investment rests on several measurable metrics. Here are the typical outcomes reported by UK manufacturers who have deployed one:

• 40–60% reduction in order-status phone calls — the most immediate and measurable impact. If your sales team fields 30 calls a day at 3 minutes each, that is 90 minutes of reclaimed time per day, or roughly 360 hours per year per salesperson.
• 7–12 day reduction in average payment cycle — when invoices are available on demand, the “I never received it” delay disappears. For a manufacturer with £5m in annual receivables, a 10-day acceleration at 8% cost of capital is worth approximately £11,000 per year.
• 15–25% reduction in order errors — when customers enter their own orders through a digital portal, transcription errors from phone and email orders are eliminated. No “I said 50, not 15” disputes. No part numbers misheard over a bad phone line.
• 20–30 point NPS improvement — customers consistently rate suppliers with self-service portals higher on satisfaction surveys. The ability to get answers at 9pm on a Sunday matters tremendously in manufacturing environments where production never sleeps.
• 10–15% reduction in credit note volume — fewer order errors means fewer returns, fewer credit notes, and less finance team time spent reconciling discrepancies.

How to calculate your own ROI: Add up the annual cost of the time your team spends on order-status calls, invoice re-sends, stock checks, and order entry. Divide by the typical reduction percentages above. Compare that to the total cost of ownership of the portal over three years. Most manufacturers we work with see payback within 6–14 months.

Here is a worked example for a typical mid-market manufacturer:

Even with conservative estimates, the payback period is under 12 months, and the five-year return is in the hundreds of thousands of pounds. These numbers are consistent with what our clients report and what the broader industry literature documents.

Frequently Asked Questions

Is a customer portal secure?

Yes, when built correctly. A properly engineered portal uses OAuth 2.0 for authentication, TLS 1.3 for transport encryption, and field-level data filtering to ensure customers see only their own data. The portal should never have direct database access to your ERP — it communicates through the API layer, which enforces your existing security model. Look for UK-hosted cloud infrastructure, regular penetration testing, and SOC 2 or ISO 27001 aligned practices from your provider.

How long does it take to build?

Timeline depends on scope. A read-only portal with order tracking and invoice download typically takes 6–8 weeks from kick-off to launch. A full portal with write-back (reordering, returns, queries) takes 8–12 weeks. Add 1–2 weeks for customer pilot testing before full rollout. ISV add-ons can be faster (2–6 weeks) because they are pre-built products you configure rather than build.

Do I need to replace my ERP?

No. An ERP-connected customer portal does not replace your ERP — it extends it. Your ERP remains the system of record for all data. The portal reads and writes through the ERP’s API. There is no data migration, no duplicate database, and no disruption to your existing ERP operations or upgrade path.

Will my customers actually use it?

Adoption depends on how you launch it. The most successful portal launches make the portal the easiest way to get information: include a link to the portal in every email signature, stop sending invoice PDFs by email and direct customers to the portal instead, and have your sales team show customers how to use it during their next call. Most manufacturers see 60–80% active adoption within 90 days of launch. The remaining 20–40% tend to be low-volume customers who rarely need order information anyway.

Does it work on mobile?

A modern portal is built responsive-first, meaning it works on any device with a web browser. Your customers can check order status on their phone, download invoices on their tablet, or place reorders from the warehouse floor. If your customers genuinely need a native mobile app (iOS/Android), that is possible but typically adds 4–6 weeks and 30–50% to the build cost. Most UK manufacturers find that a well-designed responsive web portal meets their customers’ mobile needs.

Can I connect multiple ERP systems?

Yes, with the adapter pattern described above. If you run, for example, Business Central for your UK operation and a separate ERP for your European subsidiary, the portal can present a unified view to customers who deal with both. The adapter layer routes each request to the correct ERP based on the customer record. This is a significant advantage of custom-built portal software over ISV add-ons, which typically support only one ERP.

Can I brand it as my own?

Absolutely. A custom-built portal is your application. Your logo, your colours, your domain name, your URL. There is no third-party branding, no “Powered by” footer, no vendor UI that you are forced to work around. The portal looks and feels like a natural extension of your business, which is important when your customers judge your digital capability based on what they see.

What are the ongoing costs after launch?

For a custom-built portal, ongoing costs cover cloud hosting (AWS or Azure), security patching, API maintenance, monitoring and support, and feature evolution. Expect £500–£1,500 per month depending on usage volume and support level. ISV add-ons charge ongoing licence fees which are typically higher. Power Pages costs vary with usage. In all cases, factor in internal costs for customer support, training, and ongoing content management.

Is a Customer Portal Right for Your Business?

A customer self-service portal makes sense if:

• Your team spends more than 30 minutes per person per day answering customer queries that the ERP already has data for
• You have more than 50 active customers who place orders or need order information regularly
• Your customers have asked for online access to their account information
• You are losing business because competitors offer a better digital experience
• Your payment cycles are longer than your industry average
• You want to reduce order errors from phone and email communication

It probably does not make sense if you have fewer than 20 active trade customers, if your customers overwhelmingly prefer phone interaction and are unlikely to adopt digital channels, or if you are planning an ERP replacement within the next 12 months (in which case, wait and build the portal on the new system).

---