The portal delivers a complete self-service estate across the customer lifecycle. On the financial side it presents every invoice with its status, ageing and remaining balance, renders and downloads the source document, and accepts payment inline through stored methods, card, direct debit or bank transfer, with part-payments, consolidated settlement of multiple invoices and automatic receipting. Statements of account and downloadable transaction histories are available on demand.

On the commercial side customers view live orders from confirmation through fulfilment, track shipments with carrier references and delivery milestones, and review quotations and renewals. On the service side they raise support tickets against a guided intake, attach evidence, follow status and threaded correspondence, and consult a published knowledge base before ever opening a case. A document library holds contracts, signed agreements, certificates, delivery notes and specifications, each version-controlled and searchable. Finally, an administration area lets the customer maintain company and contact details, delegate access to colleagues with scoped permissions, set communication and notification preferences, and manage the users who act on the account. Every action is available without a phone call, and every result is written straight back to the systems of record.

At the centre of the portal sits the account: the customer organisation as the business knows it, the single anchor to which everything visible in the portal belongs. An account carries one or more people who are entitled to sign in, and those people hold roles that decide what they may see and do. A finance contact settles invoices; a logistics contact tracks deliveries; an administrator governs the others. Entitlement is the quiet backbone of the whole domain: nothing appears in the portal unless the signed-in person is permitted, through their account and their role, to see it.

Around that anchor gather the transactions that describe the relationship in motion. Some are financial, such as invoices and the payments that discharge them; some are commercial, such as orders and the shipments that fulfil them; some are conversational, such as support cases and their exchanges. Each is owned by the account and understood in the customer's own terms rather than in internal jargon. Binding the account and its transactions together is the document: the contract, statement, receipt or delivery note that gives a transaction evidential weight. Because the portal reflects rather than duplicates the back office, each of these concepts is a living view of a record that operations already trust, so what the customer reads is always what the business itself holds.

The recurring journeys are deliberately short. In the pay an invoice flow a customer opens the outstanding items, selects one or several, confirms the amount and settles with a stored or entered method; the payment posts, the balance updates and a receipt is issued in the same motion. In the raise and track a case flow the customer is guided through structured intake that captures the right context up front, attaches supporting files, and then follows the ticket through acknowledgement, progress and resolution with full visibility of every reply.

The track an order flow moves from confirmation through picking, dispatch and delivery, surfacing carrier detail and revised dates as they change. The retrieve a document flow lets a customer search the library, open the current version of a contract or certificate and download it for their own records. Underpinning all of these, the manage access flow lets an account administrator invite colleagues, assign roles, revoke access and adjust notification preferences without involving the vendor. Each workflow ends in a definitive state and a notification, so the customer is never left guessing whether an action landed.

The detail is where a portal earns trust. Financial presentation follows disciplined accounts-receivable practice: invoices carry correct ageing buckets, credit notes and adjustments net against balances, multi-currency accounts display in their own denomination, and partial and over-payments are reconciled cleanly rather than left floating. Payment handling is tokenised so that card and bank details never rest in the portal, and every settlement produces an auditable trail linking payment, invoice and receipt.

Access control is equally rigorous. Authentication supports single sign-on and multi-factor challenges, sessions are governed by policy, and every view and action is checked against entitlement so that one account can never glimpse another's data. Service interactions respect the commitments that matter to customers: response and resolution targets are visible, priority is explicit, and case history is immutable. Documents are held under version control with retention rules, controlled sharing and a record of who accessed what. Accessibility and responsive behaviour are treated as requirements, so the same capabilities work on a phone at a loading dock as on a desk. Throughout, the portal keeps a complete activity log, giving both parties a defensible account of who did what, and when.

The Customer Portal is valuable precisely because it is not a standalone application; it is the external face of the wider platform. Its invoices, balances and payments are the live records of the Accounting module, so a settlement in the portal reconciles instantly against the general ledger and the customer's statement never drifts from the books. Its support cases are genuine tickets in Service and Support, sharing the same queues, priorities and service commitments that internal agents work against, which means a customer and an agent are always looking at one shared case.

Every contract, certificate and delivery note is served from Document Management, inheriting its version control, retention and permissions rather than copying files into a separate store. Orders and shipments reflect the state held in the suite's sales and fulfilment records, and identity flows from the platform's central access and permission model. Because these connections are native, the portal needs no synchronisation layer and carries no risk of a stale mirror: it is a permissioned lens onto the same data the business runs on, which is what lets it be simultaneously self-service for the customer and authoritative for the enterprise.

AI Workers operate in the portal as first-class participants rather than a bolted-on chatbot. A customer can ask, in plain language, which invoices are overdue, when an order is due to arrive or what a contract clause commits them to, and the Worker answers from the account's own permissioned data, honouring exactly the same entitlement boundaries a human user faces. Beyond answering, Workers execute: they draft a payment against selected invoices for the customer to confirm, open a well-formed support ticket from a described problem, or assemble the right documents for a request.

On the business side, Workers watch for anomalies and exceptions and raise them early, flagging an invoice slipping toward a credit hold, a shipment running late against its promise or a case breaching its response target. They extract structure from what customers upload, reading a purchase order or remittance advice and mapping it to the matching records so intake is clean. They provide decision support by summarising an account's standing before a renewal conversation. And they act as review and approval nodes inside workflows, so a large refund, a contractual change or a sensitive access grant can route through a Worker that checks policy and evidence before it advances, with a human retaining the final say. The effect is a portal that is not merely a window but an active, accountable participant in the relationship.