Government payments software company
Tax offices collect from every channel and balance each month to the cent
Sheriffs' tax offices ran property tax on an older desktop system. We treated the replacement as an accounting system first: counter, mail, lockbox, mortgage files, swipers and the online portal all post to one tax notice, with each office's rules in its own settings.
Government, Legal & DefenseProperty tax collection platformModernized a live product
The challenge
Offices needed one web system for the whole tax year, and every change order, partial payment, reversal or redemption ripples into batches, distribution checks and month close.
What we did
We studied how the old system recorded transactions, then built a multi-tenant back office where every channel posts to one notice and each office's rules live in its own settings.
The outcome
The platform runs the full tax year for several tax offices and has carried them through several tax seasons, with new offices joining on their own settings.
- Tax year
- Roll import to distribution checks in one system
- Payment channels
- Counter, mail, lockbox, mortgage files, swiper, online
- Roles
- Collectors, balancers and admins in each office
- Deployment
- Separate QA and production per office on AWS
The starting point
Sheriffs' tax offices collect property tax for their area every year and disburse it to receiving entities, including pension and revenue sharing. Collectors take payments at the counter and by mail, balancers close the batches, and each month closes with printed distribution checks.
What had to change
Offices ran the tax year on an older desktop collection system, and one office kept its prior years in an AS400 system. They needed one web system for the whole year: roll import, payments from every channel, change orders, refunds, tax sales, redemptions and disbursement.
What could not break
- Money reconciles daily and monthly, and audits need tax records reports by date
- Every payment channel posts to the same tax notice
- Each office keeps its own roll layout, fees, interest rules, letters and receiving entities
- A new office brings its prior years of data with it
- Work runs around the annual tax season and tax sale dates
The calls we made
We treated it as an accounting system first: if a payment, change order or reversal cannot be traced into batches, checks and month close, it is not done.
- 01
Learn the old system's transactions first
How the desktop system recorded transaction types, log entries and address history showed what the audit trail had to hold, so an SRS, role prototypes and an ERD for accounts, batches and transaction breakdowns came before code.
Ruled outCopying the old screens without the transaction model behind them.
- 02
Configure each office, never fork the product
Roll layouts, fees, interest on adjudicated parcels, homestead exemptions, letters and receiving entities differ per office, so they live in each office's settings and roll import on one codebase.
Ruled outA separate build for each office.
- 03
Every channel posts to the same notice
Counter and mail payments, lockbox files, mortgage servicer files, in office swipers and the online card portal all land on the notice the collector sees, so each batch balances and the account keeps one history.
Ruled outA ledger per channel, reconciled by hand.
- 04
Bring offices on one at a time
Each new office got its own roll import, settings, QA and production environments and converted prior years, so the offices already live kept collecting.
Ruled outMoving every office onto the platform in one cutover.
- 05
Trace every change through the money
A change order, partial payment, reversal or redemption ripples into batches, distribution checks and month close, so impact analysis on every change became a rule, backed by test case suites and a regression sheet.
Ruled outJudging a change by its own screen alone.
How the system fits together
What we built
Accounts with their full history
Each notice keeps partial, protested and prior year payments, overpayments, refunds, address history, other owners and notifications, and a corrected notice prints from the same screen.
Batches, month close and disbursement
Collector, balancer and admin roles work in batches, and month close distributes the money collected and prints checks to every receiving entity, including pension and revenue sharing.
Receipts, letters and reports
Receipts by print, email and text, letters for each office, and tax records, batch collection, distribution, reversal, protest and change order reports.
Collection on one notice
Payments by cash, check, card and in office swiper, multi parcel payments and payment scanning, plus lockbox and mortgage servicer files, all post to the notice the collector sees. Change orders arrive by file or on screen.
Tax sale and redemption
Tax sale, adjudication, redemption bills and certificates, quit claims, interest and penalties, with a tax sale file exported to an outside tax sale service.
How it works
Import the roll
Each office loads the assessor's tax roll in its own layout, creating accounts, parcels, owners and tax codes for the year.
Take payments
Payments arrive at the counter, by mail, through lockbox and mortgage files, by swiper or online, and post to the same notice.
Apply changes
Change orders, partial and protested payments, overpayments and refunds update the account and its history.
Balance the batch
Balancers close each batch, and the batch totals feed the daily and monthly reconciliation.
Close and disburse
Month close distributes the money to each receiving entity and prints the distribution checks and reports.
A closer look
What changed
Tax offices moved the full tax year onto one web platform, from roll import to distribution checks, and several offices have run on it through several tax seasons. New offices joined with their own settings and converted prior years while the others kept collecting.
Under the hood
- Datics role
- Modernized a live product
- Payments
- NMI gateway for card and ACH with a processor per office and a separate convenience fee leg, in office card swipers, and a webhook that handles ACH reversals.
- Files in and out
- Assessor roll and change order files in each office's layout, lockbox files and payment files from three mortgage servicers in, and tax sale files out.
- Data boundary
- Taxpayer and bidder records are personal data, SSN fields on bidder pages are masked or hidden, and card data goes through the gateway.
- Deployment
- Dockerized Django REST backend and React frontends on AWS, with frontends on S3 and CloudFront and separate QA and production environments per office.
Data and retrieval
Cloud and infrastructure
Apps and APIs
Also in the stack
How it shipped
A public card portal first
An online card payment portal for one office came first, and it became the taxpayer facing payment layer of the platform.
Discovery on the old system
An SRS, a study of how the desktop system recorded transaction types and log entries, clickable prototypes for the admin, collector and balancing roles, and an ERD.
First sprints, offices live one by one
Accounts, parcels, tax codes, receiving entities, batches and roll imports, then production for several offices, each with its own roll and settings, behind a test case suite.
Deeper payment and sale flows
The redemption workflow, quit claims, overpayments, email receipts, a two step check import and posting from the online card portal.
New offices on the same codebase
Each new office came on with its own roll import, settings, QA and production environments and converted prior years, and demo sites let prospective offices try it first.
Requirements before code
An SRS, a study of the old system's transaction types, role prototypes for collectors, balancers and admins, and an ERD came before the first sprint.
Built from office staff input
Features came from tax office staff recommendations, and much of the edge case knowledge, such as interest on adjudicated parcels, came from them.
Sprints, office by office
We shipped in two week sprints and brought offices on one at a time, so the offices already live kept collecting.
What this unlocked
Next on the list are letter templates with dynamic variables, faster tax roll loading per office, general ledger integration, month end close and prior year data conversion.
Related work
Have a product with the same kind of constraints?
Tell us what already exists and what you want it to do. We will tell you what it takes.