Revenue submission is a digital workflow that lets departments taking occasional payments record what they collected and forward it electronically to a central Finance team, instead of dropping off paper forms and cash bundles. Each submission moves through a submit-review-post cycle: the originating department enters the detail, Finance reviews and accepts it, and the accepted total feeds a deposit entry and general ledger posting.

‍

In a large government, most money still flows through a handful of high-volume counters: tax, utilities, permits. But dozens of smaller offices may also collect money now and then. A parks department sells a pavilion rental. A library collects a lost-book fee. A public works crew takes a check for a curb-cut deposit. These departments do not need a full cashiering station, but the money they collect still has to reach Finance, get recorded correctly, and reconcile against the bank deposit. Revenue submission is the mechanism that connects those low-volume collectors to central Finance without a stack of paper.

‍

‍

Why does paper revenue submission create reconciliation risk?

‍

The traditional process is manual and fragile. A department fills out a transmittal form, staples it to the checks and cash, and either walks it to the Finance counter or sends it through interoffice mail. Finance receives the packet, re-keys the totals, decides which accounts to credit, and folds it into the day's deposit. Every step is a place where the record can drift from the money.

‍

Common failure points are familiar to anyone who has closed a government month-end:

‍

• Transcription errors. A total is re-keyed by hand, and a transposed digit means the submitted amount no longer matches what physically arrived.
• Missing or vague account coding. The department writes "misc revenue" and Finance has to guess or chase down which fund and object code the money belongs to.
• Timing gaps. A packet sits in interoffice mail for two days, so the collection date and the deposit date fall in different periods.
• No audit trail. When a total is questioned weeks later, there is no timestamped record of who submitted what, who accepted it, or when.

‍

None of these are unusual. They are the ordinary friction of moving money through paper, and they compound at scale. An auditor tracing a bank deposit back to its sources has to reassemble a chain that lives partly in a folder, partly in someone's memory, and partly in a ledger entry keyed days after the fact.

‍

‍

How does the submit-review-post cycle work?

‍

A digital revenue submission workflow replaces that paper chain with three defined stages, each producing a record that the next stage inherits.

‍

Submit. The originating department enters the revenue at the point of collection: amounts, payment types (cash, check, card), and the accounts to credit. Because the coding happens where the collection happens, the person who knows what the money is for is the person recording it. Check detail can be captured up front, and the submission carries a timestamp and a named submitter from the moment it is created.

‍

Review. The submission arrives in a Finance queue rather than a physical inbox. A finance reviewer checks the coding, confirms the totals, and either accepts the submission or returns it with a note. Nothing posts to the ledger until Finance has approved it, so central control over the chart of accounts is preserved even though the data entry is distributed.

‍

Post. Once accepted, the submission's totals feed a deposit entry and a general ledger posting. The department that collected the money never touches the ledger directly, and Finance never re-keys the department's numbers. The same figures flow from collection to deposit without being retyped.

‍

The core benefit is simple: the number entered by the department that collected the money is the number that reaches the ledger, with a reviewer in between and a timestamped record at every step.

‍

‍

How does digital submission feed deposit entries?

‍

The reconciliation value comes from continuity. In a paper process, the deposit and the department's record are assembled separately and then matched by hand. In a digital submission workflow, the deposit entry is built from the accepted submissions themselves, so the deposit and its supporting detail share a single lineage.

‍

That means when the bank deposit clears, Finance can trace it back through the accepted submissions to the individual collections that made it up, each with its own account coding, submitter, and timestamp. The audit question changes from "where did this $3,400 come from?" to "here are the eleven submissions that total $3,400, who entered them, and when Finance accepted them."

‍

For governments that manage receipts through Teller Government Cashiering, the Revenue Submission module is designed to sit alongside the main cashiering platform for exactly this pattern: low-volume departments submit digitally, Finance reviews in a central queue, and accepted revenue feeds deposit and general ledger workflows rather than arriving as paper to be re-entered.

‍

‍

Which departments benefit most from revenue submission?

‍

Revenue submission is aimed at the long tail of collectors, not the high-volume counters. A cashiering station makes sense where staff process payments all day. Revenue submission makes sense where a department collects money often enough that it matters, but not often enough to justify a full point-of-sale setup or dedicated cashier training.

‍

Typical candidates include:

‍

• Parks and recreation offices taking facility rentals, program fees, and equipment deposits.
• Libraries and cultural facilities collecting fines, replacement fees, and event revenue.
• Public works and engineering handling permit deposits, inspection fees, and one-off reimbursements.
• Special districts and regional authorities that collect on behalf of a central finance function they do not staff themselves.
• Elected offices and small program units receiving occasional payments that still have to be recorded against the correct fund.

‍

The shared trait is distance from Finance. These departments are physically or organizationally separate from the treasury team, and paper is what has historically bridged that gap. Digital submission closes it without asking every small office to become a cashiering operation.

‍

‍

What should finance teams look for in a submission workflow?

‍

When evaluating how a low-volume submission process should work, a few characteristics separate a genuine control improvement from a digital version of the same paper problem:

‍

1. Coding at the source. The department that knows what the money is for should assign the account coding, not a downstream reviewer guessing after the fact.
2. A real review gate. Finance should have to accept a submission before it posts, preserving central control over the ledger while distributing the data entry.
3. A complete audit trail. Every submission should carry a submitter, a reviewer, and timestamps that survive into the deposit and ledger records.
4. Straight-through posting. Accepted totals should feed deposit entries and general ledger postings without being re-keyed, because re-keying is where reconciliation risk re-enters.

‍

Handled well, revenue submission is less about technology than about discipline: it forces the collection record and the money to stay aligned from the counter to the bank. For a finance director, the payoff is a month-end where every dollar in the deposit traces cleanly back to the department that collected it, with no paper packet to reassemble and no re-keyed total to reconcile.