-
PMP, Solutions Engineer, Catalis Tax & CAMAView all postsA CSPO-certified leader, he delivers enterprise tax software via strategic planning, client collaboration, and agile implementation expertise.
Key takeaways from Catalis’ “Built for Virginia” webinar on modernization, data readiness, and evaluating your next tax management system.
For many Virginia tax offices, the question is no longer whether modernization is coming, but when. Aging platforms, shifting legislation, rising cybersecurity expectations, and workforce turnover are all raising the stakes. Localities need to know how prepared they are for the next decade of tax administration. After 30+ years of supporting Virginia tax offices, clear patterns emerge. So do common mistakes in how offices evaluate and implement a new Virginia tax management system (TMS).
Decades of helping Virginia jurisdictions modernize treasury operations inform this recap. It covers practical considerations, common challenges, and best practices for selecting and implementing a new TMS.
Below is a closer look at the insights that matter most to offices actually going through this process.
1. Your TMS is the hub — and that creates a hidden integration burden
Most offices don’t think of their tax system as a data hub until they try to replace it. In reality, a modern TMS has to manage a constant flow of information in both directions:
Coming in: CAMA imports, GIS imports, DMV imports, JD Power vehicle valuations, DGIF/DWR and Coast Guard files, and data from taxpayer self-service portals (business license applications, monthly fiduciary tax filings).
Going out: real-time balance updates to the payment portal, GL feeds for billing/collection/adjustment activity, bill files to the print vendor, and curated data subsets to business intelligence platforms.
The insight worth sitting with is that asking “does it integrate?” is not enough. The better question is how it handles the exceptions. What happens when a record comes in missing data or in the wrong format? Does the system reject the whole file or just that record? Can staff fix and reprocess it without IT intervention?
One approach is a centralized “job orchestration system.” It provides a single administrative view of imports, exports, and background jobs. Built-in exception handling lets staff correct bad records without a manual workaround. They also avoid importing a whole new file.
What to ask vendors: Show us how staff resolves failed imports and data validation errors.

Data hub administrative dashboard shows a 14-day history of data feeding into and out of the system, plus a list of scheduled/running background jobs.

An SFTP parcel import paused “awaiting review” after a formatting or missing-data issue is found.

Staff can correct and re-verify individual records before they’re processed — whether the file came from CAMA, DMV, or another source, the exception handling works the same way.
2. “Clean data” is a process question, not a data question
Every office has a version of the same story. A workaround built years ago, maintained by one person, is still quietly running the show. The risk isn’t the workaround itself. It’s what happens when that person leaves and nobody understands why the spreadsheet does what it does.
Data conversion during a system migration is often the moment these inconsistencies surface. The Catalis team’s recommendation was specific. Audit your data internally before going to RFP, not after selecting a vendor. Look for:
- Addresses or parcel data that have drifted out of sync
- Historical records calculated under rules that have since changed (see the prorating example below)
- Manual reconciliation steps that exist only because “that’s how we’ve always done it”
The goal isn’t to arrive at a new vendor with perfect data; it’s to know where the gaps are so the conversion process (which will surface them anyway) doesn’t become a surprise.
What to do now: Identify the spreadsheets or manual processes that only one employee understands.
3. A real example of why tax rules can’t be “one size fits all”
One question that came up during the webinar involved a unique Virginia tax administration challenge: what happens when a locality changes from non-prorating to prorating for a particular tax item?
We’ve seen this play out in practice. Several Virginia localities moved from non-prorating to prorating for certain personal property tax items back in 2013, and at least one more made the same change as recently as 2016. In each case, the policy change itself was straightforward, but it created an important systems requirement: tax years before the change still had to calculate under the old non-prorating rules, while tax years after it needed the new prorating methodology in the same system, indefinitely.
That’s a good example of why tax management systems need flexibility built in. Tax administration isn’t static. Local ordinances change, tax policies evolve, and jurisdictions periodically adjust how taxes are assessed, billed, or calculated. A modern TMS needs to accommodate those changes without compromising historical accuracy.
For Virginia localities in particular, it’s worth asking how a vendor handles changes to tax rules, calculation methods, or local requirements over time. The goal isn’t just to support how your office operates today, but to ensure the system can adapt as policies and regulations evolve in the future.
What to ask vendors: How does the system accommodate changes to local tax policies or calculation methodologies while preserving historical tax data and prior-year calculations?
4. Evaluation questions that go beyond “does it work”
The webinar laid out a set of questions Virginia offices are actually asking vendors, and they go deeper than feature checklists:
- Responsiveness to legal change: When an ordinance changes, how fast can the vendor implement it? Does that cost extra, or is it covered under your service agreement?
- Data ownership and location: Is your data hosted in the US? In the Commonwealth? Who legally owns it in a cloud environment?
- Shared enhancement policy: If one county pays for a new feature, does it become available to other jurisdictions on the same platform automatically, or do others have to pay to adopt it? This is a real cost consideration that’s easy to overlook.
- Performance under load: Does the system stay responsive during your busiest billing season, or does it bog down exactly when you need it most?
- Support trajectory: What does support look like a year after go-live? Three years after? Is it the same level you got during implementation, or does it taper off?
- Proven in Virginia specifically: Has the vendor actually handled the Commonwealth’s specific tax types and item types before, or would you be their first?
What to ask vendors: How are legislative changes handled, how quickly are they delivered, and are they included in ongoing support costs?
5. Different stakeholders measure “success” differently and that shapes the RFP
One of the more practical points raised: a commissioner’s office, a treasurer’s office, IT, and finance don’t want the same things from a new system, and a successful evaluation has to account for all of them.
| Stakeholder | What They’re Optimizing For |
|---|---|
| Commissioner’s Office | Fast, manageable DMV imports and early access to JD Power vehicle values so tax bills can be calculated sooner. |
| Treasurer’s Office | Speed from bill generation to portal availability, real-time payment reflection, and smooth delinquency processing including debt setoff, DMV stops, payment plans, and liens. |
| IT | Whether the platform aligns with the jurisdiction’s security framework and how much ongoing integration support is required. |
| Finance | Accurate reconciliation of general ledger feeds from the tax management system into the accounting platform. |
| Leadership | Lower costs, reduced risk, and a better taxpayer experience. |
If your jurisdiction splits these functions across multiple elected offices, alignment on priorities before the RFP goes out will mitigate significant friction later.

Configurable administrator dashboard widgets show account types, number of accounts, and bill types/items broken down by category — e.g., personal property (vehicles, trailers, mobile homes) and monthly/quarterly filings (transient occupancy, food and beverage) along with active records, total assessment, and pre-tax relief figures.
What to do now: Before the RFP goes out, have the appropriate stakeholders (commissioner, treasurer, finance, IT, etc.) identify what success looks like for them.
6. The real implementation risks, in order
Based on pattern recognition across dozens of implementations, the top risks consistently are:
- Data quality and conversion — the single biggest source of surprises
- Integrations — getting data to and from every connected vendor in the right format, on the right schedule
- Reporting — not technically hard, but tedious; offices often have hundreds of reports (bill prints, cash receipts, adjustment reports, etc.) that need to be inventoried early
- Resistance to change — mitigated through active, deliberate change management, not left to resolve itself
While every jurisdiction is different, many tax management system implementations fall in the 12- to 18-month range, particularly when multiple offices, integrations, tax types, and reporting requirements are involved. Cloud tax software for local government can help shorten implementation timelines by allowing parallel testing, running your legacy system in production while validating the same transactions in a separate cloud test environment via URL, rather than needing a fully isolated environment.
What to do now: Create an inventory of reports, interfaces, and recurring jobs before issuing a tax management system RFP.
7. If you’re still on AS400 or similar legacy systems, you have a shortcut
Offices still running AS400 or comparable legacy platforms have a specific opportunity worth naming. In any AS400 migration, offices can skip the intermediate on-prem Windows system many historically chose. That skips an entire technological generation and goes straight to a modern cloud platform.
Several common triggers push offices toward legacy tax system replacement:
- Key staff turnover, especially in IT, where one long-tenured administrator often holds undocumented “tribal knowledge” about the legacy system
- End of vendor support, since legacy systems don’t get younger and fewer people understand the underlying language or platform
- Rising insurance or operating costs for maintaining on-prem infrastructure
- Integration and reporting gaps that require manual programming to bridge
What to do now: If your office is running on-prem today, take stock of how much of that “how it actually works” knowledge lives in one person’s head rather than in documentation.
Where to start
If a tax management system evaluation is realistically on your timeline, this budget cycle, next year, or further out, three concrete steps are recommended:
- Inventory your data now. Identify likely inconsistencies (addresses, historical rule changes, manual reconciliation points) before a vendor’s conversion process surfaces them for you.
- Document your reports and workflows, including the informal, one-off worksheets nobody’s written down.
- Align stakeholders early — commissioner, treasurer, IT, and finance — on what success actually looks like for each office, before the RFP goes out.
The most successful projects don’t start with software selection. They start with preparation. Offices that understand their data, document their workflows, and align with stakeholders before evaluating vendors consistently move faster, encounter fewer surprises, and are better positioned for long-term success. Whether tax system modernization is a priority this year or several years away, those preparations provide value immediately.
Not sure where your office’s data stands, or what a realistic evaluation timeline looks like for your jurisdiction? Reach out to the Catalis team for a no-pressure conversation about your specific setup.