%402x.svg)
Government cashiering software posts receipts to a separate general ledger by splitting a single payment into two accounting events: it posts the receipt against the originating invoice in accounts receivable, then generates a deposit entry (bank debit against a revenue or clearing account) that flows to whichever system holds the general ledger. Integration plugins map each side to the correct system in real time.
This matters because many agencies do not run one system. Utility billing may live in one platform, tax in another, and the general ledger in a third. Teller Government Cashiering is built for exactly this fragmentation: a cashier takes one payment, and the software fans the accounting out to the right systems without staff re-keying anything.
What is the difference between A/R posting and GL deposit posting?
These are two distinct accounting actions that a single receipt triggers, and confusing them is where a lot of cashiering integration goes wrong.
Accounts receivable (A/R) posting answers "which bill did this pay?" When a resident pays a $240 utility bill, the receipt is applied against that specific invoice in the utility billing system. The invoice is marked paid or partially paid, the customer balance drops, and delinquency and lien processes see the payment immediately.
General ledger (GL) deposit posting answers "where did the money land, and what revenue does it represent?" The same $240 becomes a journal entry: cash or a bank clearing account is debited, and a revenue or liability account is credited. This is the entry a controller or auditor traces when reconciling the bank statement to the books.
One counter payment produces two accounting truths: the invoice it satisfies, and the ledger entry it creates. Good cashiering software keeps both accurate without a human touching either.
A retail point-of-sale system was never designed for this distinction. It records a sale, not a receivable applied against a government billing subsystem, and it has no concept of the fund accounting that governs public-sector ledgers.
Why do government agencies run A/R and the general ledger in separate systems?
It is rarely a choice. Public-sector finance typically accretes systems over decades, and the general ledger tends to be the most protected, slowest-to-replace piece of the stack.
- Different vendors solve different problems. Utility billing, tax administration, and permitting are each specialized systems with their own receivables ledgers. The enterprise general ledger is often a separate ERP or a legacy financial system.
- Fund accounting adds structure. Governments track money by fund, department, and often grant. The GL enforces that structure across every department, while individual billing systems only see their own receivables.
- Replacement risk is high. Agencies replace a billing module far more readily than the general ledger of record, because the GL is what audits, budgets, and bond disclosures depend on.
The practical result is that a counter clerk taking a permit fee and a tax payment in the same transaction is touching two receivable systems and one general ledger. The cashiering layer is what has to reconcile that in the background.
How does a single payment reach both the receivable system and the general ledger?
The mechanism is a mapping layer that sits between the counter and the back-end systems. When a payment is tendered, the cashiering platform runs an integration for each account line on the receipt.
- Lookup. The clerk searches an account or invoice. The platform calls the billing or ERP system and pulls the live balance so the amount owed is current, not a stale copy.
- Tender. The clerk takes cash, check, or card. The receipt may carry lines destined for different systems.
- A/R post. For each billed line, the platform posts the payment back to that system's receivable in real time, so the invoice reflects the payment immediately.
- GL deposit mapping. The platform maps the same amounts to the correct GL accounts, funds, and departments, then writes or queues the deposit journal entry for the general ledger system.
Because these steps are driven by configuration rather than manual entry, the clerk sees one screen and one "complete" button. The accounting complexity stays behind the interface.
Where does plugin-based integration fit in?
No two agencies have the same combination of systems, so the bridge cannot be hardcoded. Teller uses a single code base with plugin-based extensibility, so each connection is a configured integration rather than a custom fork of the product.
In practice that means a .NET plugin, a REST API call, or a SQL query can target whatever system holds the ledger. Teller runs 96+ third-party integrations in production, including the major government ERPs (Workday, Oracle, JDE, NetSuite, PeopleSoft, SAP) alongside tax, utility billing, and permitting platforms. The GL side is often a different endpoint than the A/R side, and the plugin model lets one receipt address both.
A simplified view of how one receipt line resolves to two destinations:
Keeping these as separate, configurable steps is what lets an agency change one system later without rebuilding the whole cashiering setup.
How does GL posting affect end-of-day balancing and deposits?
Real-time A/R posting keeps customer balances honest during the day, but the general ledger cares about the deposit, which is a batch concept. Cashiering software has to reconcile the two rhythms.
At close, each cashier balances their drawer: counted cash and checks against the receipts recorded. Those balanced receipts roll up into a deposit, and it is the deposit total, categorized by fund and revenue account, that the general ledger needs. Well-built cashiering software carries the fund and account coding from each receipt into the deposit summary, so the journal entry the GL receives already matches what was collected. That is what makes bank reconciliation and audit tracing straightforward instead of a monthly investigation.
When deposit entries feed the GL cleanly, the audit trail runs unbroken from an individual counter payment, to the invoice it paid, to the deposit it joined, to the journal entry on the books. That end-to-end line is the real payoff of posting receipts to a separate general ledger correctly.
The takeaway
A counter payment in a government office is never just a sale. It is a receivable applied and a ledger entry created, often in two different systems. Purpose-built cashiering software handles both from one transaction: it posts to accounts receivable so balances stay current, and it maps deposit entries into a separate general ledger so the books and the bank agree. Plugin-based integration is what makes that possible across the mix of systems a given agency actually runs.
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
