Invoices and statements
Open items, ageing, and downloadable statements, live from the ledger rather than a nightly export. When you post a credit memo, they see it immediately.
Platform · front office
Most portals are a separate application fed by a sync, which means what your customer sees is yesterday's version of the truth. Ours reads the same records your finance team does, through a permission boundary you define — so the invoice they are looking at is the invoice.
Your size, your ledger, and what your customers need to do. We will stand up a working portal on a sample.
What it does
Portals fail when they are built as a brochure with a login. These are the functions that produce repeat visits, and each one removes a piece of manual work from your side as well as theirs.
Open items, ageing, and downloadable statements, live from the ledger rather than a nightly export. When you post a credit memo, they see it immediately.
Card, ACH, or bank transfer against one invoice or a selection. Payments apply to the right open items automatically and the cash posts without a person keying it.
Quotes, change orders, milestones, and timesheets approved in the portal with a recorded identity and timestamp — which is the evidence you need when a scope dispute arrives.
Where the work is, what is next, what is waiting on them. The single biggest reduction in inbound "just checking in" email we see.
Deliverables, contracts, and reports out; W-9s, purchase orders, and source files in. Versioned, permissioned, and attached to the right record rather than lost in a thread.
A structured intake that lands against the customer and the project, so support volume becomes data you can look at rather than a shared inbox.
A customer portal is an outside party reading from the system that holds your general ledger, your margins, your other customers, and your payroll. Everything about how it is built should follow from that sentence.
The common architecture in this category is a second application with its own database, fed by a sync from the ERP. It is popular because it feels safer — the outside world never touches the real system — and it introduces two problems in exchange. The data your customer sees is stale by however long the sync interval is, which produces the phone call about a payment that cleared on Tuesday and still shows outstanding on Thursday. And you now have a second copy of customer financial data with its own access control, its own backups, and its own breach surface.
We take the other approach. The portal reads the same records, and the boundary is enforced in the query layer rather than by copying data somewhere less sensitive. A portal session is scoped to exactly one customer and cannot express a query that reaches beyond it — not by URL manipulation, not by an API call, not by an export.
Portals die from friction at the front door. We support magic-link email sign-in, which covers most small-business customers, and SAML or OIDC single sign-on for enterprise customers who require it. Sessions are short by default, and payment actions can be configured to re-authenticate regardless of session age.
The measurable return is usually in two places. Days sales outstanding falls when customers can see and pay an invoice without emailing to ask for a copy — the improvement is typically a few days, and it is the cheapest DSO reduction available to most firms. And inbound status email drops sharply once project and order state is visible, which is time your delivery team gets back rather than a line on a P&L.
This is where a lot of our engagement work comes from, and it is a genuine strength rather than a footnote. The standard portal covers invoices, payments, approvals, projects, documents, and requests. Plenty of businesses need something beyond that: a distributor whose customers need to reorder from a personalised catalogue, an MSP whose clients need an asset register, a construction firm whose owners need draw schedules with lien waivers attached.
We build those as custom modules on the same data model and the same permission boundary, hosted and versioned by us rather than handed over as a codebase you then own the maintenance of. The build is quoted at a published rate with a monthly hosting fee, which is how a bespoke portal stays a product rather than becoming a bespoke liability.
This is a portal, not an ecommerce storefront. If you need a catalogue with public browsing, cart abandonment, promotions, and consumer checkout, use Shopify and let us integrate it. We are good at authenticated, account-scoped experiences for known customers — that is a different problem.
Who uses it
Clients approve scope and see burn against retainer without a status call.
Ticket intake, asset lists, and monthly true-ups in one place.
Draw schedules, lien waivers, change orders, and progress photos.
Order status, backorders, reorder history, and self-serve reprints.
Engagement documents, invoices, and secure exchange of sensitive files.
Self-serve payment and statement access, which is where DSO actually moves.
Questions
See a working portal on a sample of your own customers before you commit to anything.