New fees start January 1. Does the online form know?

Ten weeks out: the schedule is approved, the forms aren't

Picture a mid-sized city. In October, the council approves a new fee schedule. Building permits, sidewalk café licenses, records copies and a few others go up on January 1. The ordinance is clear. The memo goes to department heads. Everyone nods.

Then January 2 arrives. The online permit form still charges the old amount because the number was typed into the form two years ago. The counter register has the new amount because someone in finance updated it. The PDF handout on the website shows the old fee, and the walk-in applicant brought a printout. Three people pay three different amounts for the same permit in the same week.

None of this is unusual, and none of it is about the council's decision. A fee change is a cutover. It just doesn't look like one, because the change is a number. This countdown is for whoever has to make that number change everywhere at once.

Eight weeks out: find every place the old amount lives

Start with a list. Not of fees, but of places each fee appears. For one common permit, it's usually longer than anyone expects:

• the online application form, and any fee calculator attached to it
• the payment page or payment vendor's configuration
• the counter register or cashiering system
• PDF handouts, fee tables and FAQ pages on the website
• form letters and email templates that quote the amount
• the phone script or cheat sheet the front desk uses
• any AI assistant or chatbot on the site that answers "how much is a permit?"
• third-party portals, such as a state system or a vendor platform you don't control

Ask each department to add to the list. The clerk who handles walk-ins will know about the laminated sheet taped to the counter. That sheet counts.

For each place, write down who can change it and how. Some are a setting. Some need a vendor ticket with a lead time. Some are a PDF someone has to re-export. Our older note on why a PDF online isn't an online service explains why those PDFs tend to linger.

Six weeks out: decide which date counts

This is the question that will cause the most arguments in January, so settle it now. An applicant starts the online form on December 29 and pays on January 3. Which fee applies?

There are a few common answers: the date the application was submitted, the date it was deemed complete, or the date of payment. Some places honor the old fee for anything started before January 1, within a grace period. The right answer is whatever your ordinance and your attorney say. The software problem is making the system follow it.

If the rule is "submission date," the form needs to know when an application was submitted and keep that date even when payment comes later. If the rule is "payment date," the amount has to be recalculated at payment, and the applicant should be told before they're surprised. Write the rule in one sentence and give it to whoever configures the form.

If a vendor runs the form or the payment page, this is also the moment to ask them a few plain questions. Can a fee change be scheduled for a future date, or does someone have to make it live on the day? Is the amount stored in one place, or typed into each form separately? Will in-progress applications keep their original amount? How much notice do you need, and who on your side approves the change? Their answers tell you a lot about the system you bought, and they're worth having in writing before the next contract renewal.

Four weeks out: test the new numbers before the holidays

Most vendors and IT teams can schedule a change for a future date. Use that if you have it. If you don't, you'll need someone to make the change on December 31 or January 1, which is a holiday for most staff. Plan for that on purpose.

Either way, test in December. Enter a few sample applications in a test environment with a January date and check the totals, including any processing or convenience fee your payment vendor adds on top. Check that the receipt shows the new amount. Check that the confirmation email doesn't quote the old one.

Then tell people. Put a short notice on the fees page that says what's changing, from when, and how the date rule works. People are much less upset by a fee increase they were told about than by one that showed up at the counter.

January 1: check the live forms on the first morning

On the first business day, have one person go through the list again, this time on the live sites. Open each form, start an application, and look at the amount before paying. Pull a printed handout from the rack. Ask the chatbot. It takes an hour.

Anything that's wrong gets fixed that day. Note any applications that went through at the wrong amount so finance can deal with them now, not when the monthly reconciliation turns them up. This is the same idea as not leaving people to visit the desk anyway: if the online path is wrong, people stop trusting it.

Put this into practice

This week, pick the three fees that change most often or affect the most people. For each, make the list of places it appears, with an owner and a change method for each. Write the one-sentence date rule. Book a December test and a January 2 check on someone's calendar now.

Then keep the list. Fee schedules change again, and next year's cutover will take a fraction of the time.

It also helps to name one person as the owner of fee changes across departments. Not to make every change, but to hold the list, chase the owners, and run the January check. Without that person, each department updates its own pieces and assumes someone else is handling the website.

If the fee lives in five systems that don't talk to each other, that's worth fixing, so the amount is set once and read everywhere. That's the kind of government and public sector software work we do. Talk to us.

Related work: Wellthie.