Statements and invoices
Current balance, ageing, every invoice with its original document, and a downloadable statement — which alone removes most inbound finance email.
Services
A significant fraction of what a finance team does is answer questions customers could answer themselves: what do we owe, where is that invoice, what did we order in March, can we have a copy. Every one of those is a lookup dressed up as a relationship.
Tell us what your customers ask for repeatedly. We will scope a portal around it.
The situation
Chosen from what your customers actually ask for, not from a feature list.
Current balance, ageing, every invoice with its original document, and a downloadable statement — which alone removes most inbound finance email.
Card or ACH against specific invoices through your existing processor, with partial payment and remittance detail captured rather than guessed at afterwards.
What was ordered, what shipped, what is outstanding, with tracking where the fulfilment system provides it.
For services businesses: milestones, approved deliverables, hours against budget, and unbilled work — the last one changes the invoice conversation entirely.
Contracts, certificates, signed change orders, and compliance documents in one place rather than in the sent items of whoever emailed them.
What a portal user can see is enforced in the data layer, field by field. Cost and margin sit on the same invoice record and are unreachable at any layer including exports.
Building a page that shows invoices is trivial. Building one where an external party cannot reach adjacent data is not, and the failure is rarely a visible one — it is an API endpoint that returns the full record and a front end that displays part of it.
Anyone who opens developer tools sees your cost and margin. It is one of the most common defects in customer-facing software, it never appears in testing because the interface looks correct, and it is discovered by a customer.
A portal user is an actor with field-level grants, evaluated in the data access layer. A field they are not granted is not returned — not hidden, not filtered downstream, not present in the response at all.
The same applies to exports, search results, and anything else the portal exposes. That uniformity is what makes the boundary defensible rather than merely configured, and it is the reason we build portals on the platform rather than as separate applications reading an API.
The common failure is not technical. A portal that requires a password nobody remembers, for a task easier to accomplish by email, will be ignored, and the finance team will keep answering the same questions while paying for the portal.
So: magic-link access rather than passwords, deep links from invoice emails straight into the relevant page, and mobile that works properly because a surprising share of statement lookups happen on a phone. Every one of those is small and each is the difference between adoption and a line item.
Customers running a portal for six months typically report a substantial drop in inbound finance email and faster payment, mostly because the invoice, the statement, and the payment button are in the same place.
The unbilled-work view is the one that surprises services firms. Customers who can see accumulating unbilled hours ask about them, which is a much better conversation than the one that starts with an unexpected invoice.
Where to start
Field by field, what a customer may see. This is a business decision, not a technical one, and it is where most of the conversation happens.
Your identity, your domain, your language. A portal that looks like a vendor product gets used less than one that looks like yours.
Including adversarial testing against the API directly rather than through the interface, because that is where the leaks are.
A subset of customers first, feedback collected, then wider. Portals launched to everyone at once tend to surface their gaps loudly.
Questions
Tell us what customers ask for repeatedly. That list is the portal specification.