A municipal revenue operation runs on two complementary primitives: a target that says where the operation is going, and a settlement batch that says where it ended up. Without the target, the operation is a queue of inbound collection tasks with no prioritisation, no performance signal, and no way to tell whether a collector, a district, or a quarter is on track. Without the settlement batch, the operation is a stream of payments that no one has reconciled against the originating invoices, the tax periods, or the financial year — and the year-end report is a spreadsheet exercise that an auditor will eventually reject. GovRevenue's Collection Targets (أهداف التحصيل) and Settlement Batches (دفعات التسوية) are the two modules that close this loop. Collection Targets set the goal at the level of a municipality, a district, a revenue classification, a collector team, or a financial quarter; Settlement Batches reconcile every payment received against the originating invoice, tax period, and revenue classification at the close of each financial period. This deep dive unpacks how the two modules chain together and how they connect daily field activity to the year-end audit.
Why targets and settlement batches are paired primitives #
Most municipal finance systems treat targets and settlement batches as separate concerns owned by different teams: targets belong to the operations director who runs the field collectors, settlement batches belong to the finance director who closes the books. The two teams use different tools, meet in different forums, and produce different reports — and the gap between them is where revenue leakage lives. A collector who hits her individual target but whose payments do not reconcile against her invoices at year-end is not actually a high performer; she is a flag for either data-quality failure or, worse, fraud. A district that misses its target but whose settlement batch shows a surplus against invoiced revenue is not actually underperforming; it is a flag for either stale invoicing or, worse, off-book collection. The two signals only make sense together, and GovRevenue's design reflects that: Collection Targets and Settlement Batches share the same revenue classification hierarchy, the same financial-year scope, and the same municipality scoping — so a supervisor comparing the two sees the same structure on both sides.
Generic accounting tools and mainstream field-data apps do not pair these primitives. A tool like QuickBooks has no target entity at all; a tool like SAP FICA has settlement batches but no field-level target. The result is that operations and finance live in different worlds, and the gap between them is bridged by spreadsheets, manual reconciliations, and quarterly fire-drills that produce a number that everyone agrees to disagree with. GovRevenue's design eliminates that gap by making both primitives first-class entities in the same platform — the operations director's target dashboard and the finance director's settlement-batch report draw from the same data, scoped the same way, with the same audit trail. The supervisor sees both signals on the same screen.
How Collection Targets are modeled #
Collection Targets is a hierarchical goal-setting module. A target can be set at the level of a municipality, a district (through Organization & Geography), a revenue classification (through Revenue Catalog), a collector team, or an individual collector — and the levels roll up cleanly. A municipality-level target of SAR 500 million for financial year 2025 cascades to district-level targets for each of the municipality's five districts, which cascade to classification-level targets for trade licenses, utility billing, and municipal leases within each district, which cascade to team-level targets for each field-collector team assigned to that district and classification. The cascading is not a manual exercise; the module distributes the parent target across children proportionally to historical collection patterns, with manual overrides available for the operations director. Once approved, the target is locked for the financial year, and progress is tracked daily against actual collections through the Payments module.
Each target carries progress metrics that the operations director's dashboard surfaces in real time: total target, total collected, percentage achieved, days remaining in the financial period, projected completion at current pace, and a list of collectors or teams whose pace is below the trajectory. The dashboard draws from the same Payments records that the Settlement Batches module will reconcile at period close — so a collector who logs a payment today sees that payment reflected in her target progress immediately, and the same payment will appear in the settlement-batch report at month-end. There is no separate 'target' data store and 'settlement' data store; both modules consume the same Payments records through the same audit trail. The Workflow Routing module uses target progress as one input for click-priority ranking in the Daily Assignments queue: a debtor whose invoice value moves a collector materially closer to her target is surfaced ahead of a debtor whose invoice value is immaterial, all else equal. The target is not a report; it is an operational signal that drives daily field activity.
How Settlement Batches are modeled #
Settlement Batches is the reconciliation primitive that closes the loop. A settlement batch is a structured record that pulls every payment received during a specified period — a day, a week, a month, a quarter, or a financial year — and joins each payment to its originating invoice, revenue classification, tax period, and municipality. The join is not a lookup; it is a structural relationship that exists because every payment in GovRevenue is created against an originating invoice, which carries a revenue classification, which carries a tax-treatment rule, which carries a tax period. The settlement batch does not 'find' the invoice; it consumes the relationships that already exist. The result is a reconciliation report with one row per revenue classification showing total invoiced, total collected, total outstanding, total tax applied, and total tax collected — scoped to the period and the municipality. The report is signed with the registry key and sealed against the financial year; the audit trail preserves every payment, every join, and every aggregation for the statutory retention period.
The reconciliation surfaces mismatches that the operations and finance teams need to address. A payment that cannot be joined to an originating invoice is flagged as an 'unmatched payment' — typically a bank transfer whose reference does not match an invoice number, requiring manual reconciliation. An invoice whose total collected exceeds the invoiced amount is flagged as an 'over-collected invoice' — typically a duplicate payment that requires a refund workflow. An invoice whose tax applied does not match the tax treatment of its revenue classification is flagged as a 'tax mismatch' — typically a configuration error in the Revenue Catalog that requires correction before the settlement batch can be signed. Each mismatch has its own workflow, routed through Workflow Routing to the right team, with a deadline tied to the financial period's close. The settlement batch is not signed until all mismatches are resolved or formally accepted — which is what makes the signed report defensible to an auditor.
A real-world scenario: monthly close for an Abu Dhabi municipality #
Consider an Abu Dhabi municipality running a monthly close on GovRevenue. On the first business day of each month, the finance director opens the Settlement Batches module, selects the prior month as the period, and runs the reconciliation. The module pulls every payment received during the prior month — bank transfers, card payments, cash payments recorded by field collectors through the Payments module — and joins each to its originating invoice, revenue classification, tax period, and municipality. The reconciliation produces a report with one row per revenue classification showing total invoiced, collected, outstanding, tax applied, and tax collected. The director reviews the report, finds three unmatched payments (each a bank transfer whose reference was malformed), routes them through Workflow Routing to the collections team for manual reconciliation, and re-runs the batch once the references are corrected. The entire close takes four hours, not four days, and the signed report is archived in the in-country registry for the statutory retention period.
The operations director opens the Collection Targets dashboard on the same morning and sees the prior month's actual collections rolled up against the quarterly target. The dashboard shows that the trade-license classification in the central district is two percent ahead of trajectory, that the utility-billing classification in the eastern district is five percent behind, and that one specific collector team is materially underperforming against its individual target. The director drills into the underperforming team, sees that the team's Daily Assignments queue has had a higher-than-average deferral rate, and routes a supervisory visit through Workflow Routing. Both directors are looking at the same Payments records through the same audit trail — the finance director sees them as a settlement batch, the operations director sees them as target progress. The two views are reconciled by structure, not by spreadsheet, and the gap that previously lived between them is closed by design.
Year-end hard close and the audit trail #
At year-end, the financial year is hard-closed through the Financial Years module, and the year's monthly settlement batches are consolidated into a single annual settlement batch that feeds the ministry-of-finance report produced by Export & Reports. The hard-close is irreversible: once signed, the year's records are sealed against further edits, the audit trail is preserved for the statutory retention period, and the report becomes the defensible record of the year's revenue operations. The NDMO audit, the PDPL audit, and the equivalent Egyptian compliance review can sample from that report, trace each payment back to its originating invoice, trace each invoice back to its revenue classification, and confirm the entire chain against the in-country registry. A generic accounting tool cannot produce that record because the relationships between payments, invoices, classifications, and financial years do not exist as structured primitives — they are reconstructable from a flat ledger only with manual effort, and that effort is what auditors eventually reject.
A target without a settlement batch is a wish. A settlement batch without a target is a number. Pair them on the same platform and you have a defensible revenue operation.