%402x.svg)
A public-facing citizen payment portal is a website where residents pay utilities, taxes, permits, and fines online, any hour of the day. What makes it more than a standalone payment page is the connection to counter cashiering: an online payment lands in the same receipting and general-ledger workflow a clerk uses at the front desk. One receipt format, one reconciliation process, one audit trail across every channel.
Without that connection, agencies run two disconnected systems. Online payments post to one place, counter payments to another, and finance staff spend the end of each day stitching the two together by hand. The value of a portal that sits on the same cashiering layer is that the stitching never has to happen.
What does a citizen payment portal actually do?
At a basic level, a portal presents a resident with what they owe and takes payment for it. In government, "what they owe" is rarely simple. A single household might have a water bill from Utilities, a property tax installment from the Treasurer, and a building permit fee from Community Development. A well-built portal handles all of these payment types through one interface, pulling the current amount due from the system that owns each charge.
Teller Online, the citizen-facing portal that pairs with Teller Government Cashiering, works this way. A resident can look up a bill, pay it, and receive a receipt without ever calling or visiting an office. Behind that simple experience, the payment is doing the same work a counter payment does.
The goal is not a separate online system. The goal is one cashiering system that happens to have a public front door.
How does an online payment post to accounts receivable in real time?
When a resident pays a utility bill online, the portal needs to know two things: how much is currently owed, and where to record the payment once it clears. Both come from an integration with the source system, typically an ERP or a billing platform.
The sequence usually runs like this:
- The resident enters an account number or looks up a bill; the portal queries the billing system for the live balance.
- The resident pays; the payment processor authorizes the card or bank transaction.
- The cashiering layer writes a receipt and posts the payment back to accounts receivable, so the balance updates against the correct invoice.
- The deposit and general-ledger entries are generated from that same receipt.
Real-time posting matters because it prevents a common failure mode: a resident pays online, but the balance in the billing system does not clear until an overnight batch runs. In the gap, a second bill or a late notice may go out. Posting to A/R at the moment of payment closes that window.
Teller is in production with 96+ third-party integrations, including major government ERPs such as Workday, Oracle, PeopleSoft, and SAP, along with tax, utility billing, and permitting systems. That integration breadth is what lets a portal payment reach the right receivable no matter which department owns the charge.
How do multiple departments share one portal?
Government revenue is fragmented by design. Utilities, tax, courts, permitting, and parks each run their own systems and their own accounting. A citizen does not care about that fragmentation, and a good portal hides it.
The connective piece is the cashiering layer's ability to define payment types, each mapped to a source system and a set of ledger accounts. When a resident pays a parks fee and a permit fee in the same session, the portal treats them as two payment types with two different destinations, even though the resident sees one transaction and one receipt.
The distinction on the right is what separates a purpose-built government portal from a generic payment form dropped onto an agency website. A form can take money. A connected portal takes money and files it correctly.
How does reconciliation work across online and counter channels?
Reconciliation is where the portal-to-cashiering link earns its keep. At the counter, a cashier balances a drawer at the end of a shift: total the cash, checks, and card payments, compare to the system's record, and resolve any variance. Online payments do not have a physical drawer, but they still need to be accounted for, deposited, and posted to the ledger.
When both channels run on the same cashiering system, online payments flow into the same deposit and balancing workflows as counter payments. Finance sees one set of receipts, categorized by payment type and by channel, rather than two exports that have to be merged in a spreadsheet. Card settlements from the processor can be matched against the receipts the system already recorded, so a deposit is verified rather than reconstructed.
This is the difference that finance directors and auditors tend to notice first. A unified receipt trail means:
- One audit path for every dollar collected, regardless of how the resident paid.
- Consistent ledger coding, because online and counter payments of the same type post to the same accounts.
- Faster month-end close, since there is no separate online system to reconcile against the books.
Why not just use a general-purpose payment processor?
Large payment processors are excellent at moving money. They are the rail. What they typically do not do is understand the receipting and accounting side of a government transaction: which invoice a payment clears, which fund and department it belongs to, how it should appear in an end-of-day balance, and how it posts to a specific general ledger.
A citizen payment portal built on a cashiering layer occupies that accounting space. It can and usually does sit in front of a processor for the actual card and bank transactions, but the receipting, A/R posting, and reconciliation logic live in the cashiering system. That is why agencies with complex, multi-department revenue tend to want a purpose-built portal rather than a standalone processor with a checkout page.
What should an agency look for in a portal-to-cashiering link?
If you are evaluating a portal as an extension of your cashiering operation rather than a bolt-on, a few questions separate a real connection from a superficial one:
- Does the portal pull live balances from the source billing or ERP system, or does the resident type in an amount?
- Does an online payment post back to accounts receivable in real time, against the specific invoice?
- Can one portal handle payment types from multiple departments, each mapped to the right ledger accounts?
- Do online and counter payments share the same deposit, balancing, and audit workflows?
- Is the portal hosted and secured to the standards your finance and IT teams require, with encryption in transit and at rest?
When the answer to each is yes, the portal stops being a second system to manage and becomes the public-facing edge of the one you already run. Residents get to pay on their own time, and finance keeps a single, auditable record of every receipt no matter where it came from.
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
