← All use cases
Use case — Legacy & on-prem systems

Your system works. Customers just have no front door to their own accounts.

Legacy, on-prem, and custom back-office systems often run exactly as intended internally — the gap is that customers have no way to access their own records without involving your team. A customer-facing portal adds that front door without changing anything underneath. Customers get a read-only view; nothing in the source system is touched.

Right for you if the system is staying in place and customers currently have no way to get to their own account records without calling or emailing your team.

The access gap

The system isn't the problem — the gap is that customers have no way to retrieve their own records without involving your team. A customer-facing portal layer solves that without touching anything underneath.

Without a portal

  • The system runs fine internally, but customers have no self-service access to invoices, balances, or account documents.
  • Finance, ops, or support keeps extracting records from the source system and resending by email or file share.
  • Every customer request creates a manual task for an internal team member.

With a portal

  • Customers get a clean, read-only front door to their own account records.
  • The underlying system isn't touched. Nothing changes in how it runs or who can access it internally.
  • No more informal workarounds where records get exported and sent by email or shared drive.

What to launch first

  • 01
    Start with the data and documents your team already trusts

    The fastest first launch uses invoice data, PDF copies, and document exports already moving through your internal processes. Portal upload or automated SFTP polling is enough to begin. Direct API integration can be scoped where it makes sense.

  • 02
    Launch to a focused account group first, then widen

    Rather than launching to the full customer base at once, pick the accounts where self-service need is clearest, typically those generating the most manual document requests. Get the data pipeline and access model working well before expanding.

  • 03
    Choose hosted or self-hosted based on real environment constraints

    Hosted is the default and the faster path. Self-hosted makes sense when network boundaries, security policy, or ownership requirements genuinely require it — not as a default assumption.

Review your current environment

Tell us your current system, how customers get account documents today, and any hosting or network constraints. I'll recommend the safest practical first rollout.

Common questions

Can this run inside our network rather than being cloud-hosted?

Yes. Self-hosted deployment is available for environments where network boundaries, ownership requirements, or internal security policy rule out the hosted model. Hosting and deployment are discussed during the initial rollout review once we understand your environment.

How does payment status work if our system isn't directly connected?

Payment status in the portal is based on the paid amount on each invoice record. If your system delivers regular file updates, the feed keeps it current automatically. If not, admins can mark records as paid in the portal. Payment collection stays in your existing system — nothing in the portal changes that.

We're planning to replace our system eventually — is it worth starting now?

Yes. The portal runs separately from your existing system and doesn't depend on it staying in place. If you do replace the system later, the portal can potentially be reconnected — though that depends on what the new system exposes and whether it ships with its own customer portal. Either way, you don't have to wait to solve the access problem now.

How is our data — and our customers' data — kept isolated?

InvoicePortalX is single-tenant by design. Your data is not pooled with any other business's records. Each customer sees only the records they're permitted to access, and admin activity is logged.