No System is the Best System: Why Small Town Clerks Should Keep Their Spreadsheets for Payments

I spent years as small town resident watching small municipalities struggle with technology vendors who promised the world and delivered headaches. Now, building payment systems for those same towns, I've learned something counterintuitive: the best system is often no system at all.

The $50,000 Problem Nobody Talks About

Walk into any small town clerk's office in rural America and you'll find the same story. A vendor—usually Tyler Technologies, Superion, or some regional player—sold the county a "comprehensive solution" for property taxes, utility bills, or court payments. The contract seemed reasonable at first:

$30K setup fee
$1,200/month maintenance
"Integration" with existing systems (translation: you rebuild everything their way)
18-month implementation timeline
Training that assumes clerks have CS degrees

Five years later, the system works. Sort of. The clerks have learned to tolerate it. The citizens still call because the online portal is confusing. And the county is locked in because switching means another $50K investment and starting over.

But here's what nobody mentions: What were they using before?

The System That Actually Works

Before the consultant arrived, before the RFP process, before the city council approved the expenditure, there was a system already in place:

Microsoft Excel.

Or Google Sheets. Or even—and I'm not joking—a physical ledger book that someone manually types into a spreadsheet each week.

And you know what? It worked perfectly fine.

Linda in the clerk's office knew exactly which columns meant what
She could find any account in under 30 seconds
When someone called to check their balance, she pulled it up instantly
At month-end, she exported a report for the accountant
The format never changed because nothing forced it to

The only thing that didn't work was taking payments online. Citizens had to call, mail checks, or drive to city hall. That's the actual problem. Not the spreadsheet.

The Vendor's Big Lie

Enterprise software vendors survive by convincing you that your current system is inadequate. They audit your processes and identify "inefficiencies":

"You're entering data twice!" (Maybe, but it takes 10 minutes a day)
"There's no audit trail!" (The spreadsheet has revision history)
"What if Linda gets hit by a bus?" (Then we have bigger problems than software)
"You need real-time reporting!" (For a town of 4,000 people?)

They're selling solutions to problems you don't have.

The actual problem—citizens can't pay online without driving to city hall—gets buried in feature lists about dashboards, analytics, and "digital transformation."

What Small Towns Actually Need

Let's be honest about what a town of 5,000 - 20,000 people actually requires:

Citizens need to pay bills online - Property tax, utility bills, court fines, whatever
Clerks need to see who paid - Ideally same-day, definitely by next morning
It needs to cost less than current solutions - Which is either "free" (staff time calling people) or expensive vendor contracts
It needs to not break - No 3am server maintenance, no version upgrades

That's it. That's the entire requirement.

You don't need:

Predictive analytics on payment patterns
Mobile apps with push notifications
AI-powered chatbots
Real-time dashboards (who's monitoring municipal payments in real-time?)
Integration with 47 other systems

The Radical Solution: Keep Your Spreadsheet

Here's what actually works for small municipalities:

Keep using the exact spreadsheet you've used for years. Just connect it to online payments.

The workflow:

Monday morning: Linda uploads her balance spreadsheet (the same one she's used since 2015) to a shared Google Sheet
All week: Citizens go to a simple payment portal, enter their account number, see their balance, pay online
Next morning: Linda opens her spreadsheet and sees a "Payments" tab with yesterday's transactions automatically populated
Month end: She exports the same reports she always has, in the same format her accountant expects

Nothing about her actual work changes. The columns are still named whatever she wants. The account numbers follow the same format. The reports match the format in the accounting software.

The only new thing is that citizens can pay online instead of mailing checks.

Why This Works When Vendors Don't

It respects institutional knowledge. Linda has been doing this for 15 years. She knows the quirks—account 4021 is actually the Smith property that got subdivided, parcel 15-023 is the old Johnson place that they call "Johnson Farm" even though the Johnsons sold it in 1992. This knowledge lives in her head and her spreadsheet. Forcing her into a new system means rebuilding all of that institutional memory.

It eliminates training costs. There's no training. She already knows her spreadsheet. The only new skill is: "Upload this file to Google Sheets on Monday morning."

It prevents vendor lock-in. Her data stays in her format. No data migration, no export fees, no consultant needed.

It costs almost nothing. Citizens pay the convenience fee ($2 for cards, $1 for ACH). The municipality pays $0. No setup fees, no monthly minimums, no per-transaction charges to the agency.

The Objections (And Why They're Wrong)

"But what about security?" The spreadsheet never contains payment card data. Ever. That stays with Stripe (a certified PCI Level 1 processor). The spreadsheet only has what it always had: account numbers, names, balances.

"But what about backups?" Google Sheets has automatic revision history going back 100 days. That's better than most enterprise systems. We have a separate database of our own that has unlimited exports and a separate government-spec encrypted database for cold storage of your data.

"But what if someone deletes everything?" Google Sheets shows you exactly who changed what and when. You can restore any previous version with two clicks. Try doing that with most vendor systems.

"But this seems too simple to be real software." Exactly. That's the point. Simple is reliable. Simple is maintainable. Simple is what works in a clerk's office with two full-time employees and no IT department.

"How do we see who paid?" The default spreadsheet has three tabs Balance, Payments, Errors. If you choose to use out clickable form to make our form match your formats then our spreadsheets will look just like your spreadsheets. Balances, Payments, and Custom data will be in the fields they already are in your existing format.

When You Actually Need an Enterprise System

I'm not saying enterprise systems are always wrong. If you're a city of 100,000 people with complex workflows, dozens of departments, and a full IT staff, sure—buy the enterprise system.

But if you're a town of 8,000 people with three clerks managing property taxes, and those clerks have used the same Excel file for a decade without problems, why fix what isn't broken?

Add the ability to take payments online. Don't rebuild your entire operation around a vendor's idea of "best practices."

The Real Innovation

The innovation isn't building a better enterprise system. Every software company is trying to do that.

The innovation is not building a system at all, from the clerks experience anyway. It's building the thinnest possible layer between what you already have (your spreadsheet) and what you need (online payments). Believe me, it was much harder building a system that that made it so a clerk did not have to do anything differently than it was for the big contractors to build one to force them into their system.

Let citizens pay online. Let clerks keep working the way they've always worked. Charge the citizen a convenience fee and give the municipality the full payment amount. No contracts, no training, no consultant engagements.

That's not just cheaper. It's better.

The Bottom Line for Small Town Clerks

If a vendor tells you that your current process is "inefficient" or "outdated," ask them one question:

"Will your system let me keep using my current spreadsheet format, or do I have to adapt to yours?"

If the answer is anything other than "You keep using yours exactly as-is," you're not buying software. You're buying a migration project that will consume six months of your life and cost your town money it doesn't have.

The best system is the one you're already using. You just need someone to connect it to the internet.

David Roberts built DyerPay after watching small municipalities struggle with vendors who didn't understand how small-town government actually works. If your town is under 50,000 people and you're tired of enterprise systems that treat you like you're managing New York City, reach out. Let's talk about keeping your spreadsheet and just adding online payments.