Your ERP Has Been Making Decisions for You: How to Run a Blank Field Audit

A couple of weeks ago I was on a call with a client trying to figure out why a customer had been set up on thirty-day terms that nobody remembered approving.

We were walking through their process step by step, and I asked a pretty boring question. What happens when you click “new invoice”? What terms come up by default?

The owner clicked, and the invoice launched at net 30. I asked him to hit save and see what it saved as, because I was fairly sure that was exactly what everybody on the team had been doing. It saved as net 30.

What we found over the next few weeks, pulling on that one thread, is a great example of how a company ends up running by default instead of by design. Nobody in this story did anything wrong and that’s the part worth paying attention to.

Prefer listening? Check out this week’s Solo Session where I go even deeper on the topic.

Every decision made sense the day it was made

Some context on the business. They do fast-turnaround custom work for big-name brands, the kind of companies you’d recognize, and they’re staffed around the clock six days a week. A lot of their work is a rush, and a lot of it comes in from brand-new customers at hours when nobody from finance is anywhere near the building.

So a net 30 default wasn’t a strange choice when somebody made it. Large brands generally get terms. They get the work done and pay once the invoice shows up. Whoever set up the accounting system years ago picked a default that fit the customers they cared most about, and that was a reasonable call.

Then the business kept moving, and new people were added. The priority on the floor was “get the work out, take care of the customer, get them set up,” and the default settled in. The rush jobs from new customers were supposed to be due on receipt, and in a lot of cases they were invoiced that way, because an experienced person remembered to change it on each individual invoice. The customer record underneath still hadn’t been selected, and nobody could see the difference on screen.

That’s how a default system gets built. Nobody designs it. It accumulates out of decisions that each made sense in the moment, and once they’re made, they almost never get revisited.

“What we gain in flexibility, we give up in confusion”

The owner said that on one of our calls, and I haven’t heard the tradeoff put better.

The flexibility was real and it was worth something. The customer got fast service and nobody at 2 a.m. had to stop the job to chase a credit application. The cost showed up downstream, in finance and reporting and in the order statuses that had to move through their management information system (the MIS, is their production system of record that runs the floor). Every exception became somebody’s touch and somebody’s decision.

Finance had its own version of the same thing. When the person running receivables pulled the aging report, customers who routinely paid late would flag as past due every single week. So she did what any reasonable person drowning in noise would do, and changed their terms to match how they actually paid. A customer approved for net 15 who reliably paid in 45 days got updated to net 45, and the report got “more accurate.”

I firmly believe she did that with good intentions. Almost nobody makes these changes for any reason other than trying to be more efficient and trying not to deal with the noise. But look at what it did to the picture. The record now says the company agreed to 45 days when it never did. Your cash forecast is built on that record. When that same customer comes back asking for a discount, the record tells you they’re a customer in good standing on the terms you agreed to, when the truth is they’ve been taking free credit for months. One small edit changes how valuable that customer looks, and every decision about them from that point on is made on the wrong number.

It got more serious than that. While we were spot-checking accounts, someone brought up a customer that had burned them for six thousand dollars a couple of years back. Everybody on the call remembered it instantly. These were do-not-sell people, and if they ever did buy again it would be cash before production started.

Then we opened the record. There was no note, no flag, nothing marking them inactive, and the account still showed payment terms. The only safeguard the company had was whether someone with a long memory happened to take the next order.

Local efficiency, overall confusion

What connects all of these is something I talk about a lot, which is the difference between local efficiency and overall effectiveness.

People make these decisions based on the information that’s available to them. The rep taking the order at night is optimizing for getting the job moving. The receivables person is optimizing for a report she can actually work from. Each decision is efficient where it’s made, and each one pushes cost somewhere the person making it can’t see. Telling people to stop rarely fixes anything. What works is zooming out far enough to see what the decision does to the rest of the business.

To be fair to the other side of this, sometimes you do make one area less efficient on purpose because the whole operation performs better. That’s the synchronous flow lesson, where some departments should be less efficient so the whole operation moves more work. The difference is that it’s a choice somebody made with the whole system in view. A default is a choice nobody is looking at anymore.

This isn’t just an accounts receivable problem, either. I worked with a manufacturer running two business units on one ERP. One unit rarely shipped anything as its own line item, since freight was usually built into the project, so they’d been using product line types to handle shipping. That worked fine for them. The other unit shipped and invoiced every order separately, and it inherited the same setup. So every freight charge went in as a product line that was never meant to carry it, followed by extra notes and extra line item charges to make the invoice come out right. Untangling it took finance, operations, and IT in the same room, because the default belonged to all three of them and none of them had chosen it.

Flip one default and see what’s underneath

Back at our client, the first decision was simple. New accounts should default to due on receipt, because most new customers come in on a rush and haven’t asked for credit. We changed the setting on the call.

That’s when the real picture surfaced. Their accounting software held about 11,000 customer records, roughly 4,500 of them active in some way, and 2,547 of them had the payment terms field completely blank.

For years, blank and net 30 looked identical. Every one of those customers launched at net 30 on a new invoice because the software default filled the gap, and nobody could tell a customer the company had actually decided to extend credit to from one that had simply never been set up. Once the default changed, every one of those blanks started launching as due on receipt, including long-standing customers the team assumed had terms.

Expect the next part, because it will happen to you too. The person closest to receivables pushed back hard. She thought the change had just broken a pile of customer terms, and her position was that nobody should touch anything unless they were 100% sure it wouldn’t cause hours of cleanup. Normally I’d say the person closest to the pain has the best insight. In this case the change hadn’t broken anything. Those customers never had terms. The default had been covering the gap, and changing it just made the gap visible.

When you fix a default, the fix gets blamed for the problem it revealed. Plan for that conversation before you flip the switch.

The cleanup worked. A week later, it was back.

The cleanup went well. Using the team’s own records and some help from AI to pull billing details out of old emails, we wrote terms onto roughly 2,900 customer records in one sitting. Customers who hadn’t ordered in 36 months were reset to due on receipt and deactivated, which also made the accounting system noticeably faster to work in.

A week later there were already thirty-some new accounts that had been created, and the whole cycle had started again. A customer comes in overnight, gets set up fast so the invoice can go out, and the terms field goes in blank.

That’s the trap with every data cleanup I’ve ever seen. It’s not enough to identify the problem, put a stopgap in, and do the cleanup, because the cleanup fixes the data and leaves alone the thing that produced it. If you don’t change the system underneath, you’ll be running the same cleanup next year, and you’ll probably think it’s a new problem.

What designing it on purpose actually looks like

Designing this with intention started with the non-negotiables. The accounting tool stays as the financial system of record, and the MIS stays, because that’s what production runs on and it’s their source of truth. Nobody was going to rip out either one.

So the design work became a set of plain questions. How do we keep these two systems in sync? How do we spot the exceptions? What does the handoff between systems and between departments look like? What’s required, and what’s nice to have? That’s what we’ve spent the last couple of weeks unpacking, and it’s more of the work than the cleanup was.

Two things came out of it that I’d point any owner toward.

The operators shouldn’t have to do anything different. The rep taking a rush job at 2 a.m. still takes the rush job. The design lives in the tool, so the system executes the process we defined instead of depending on someone to remember to change a field. The same pass strips out the redundant tags and notes that repeated the same information in multiple places, because every one of those was another spot where there could be a discrepancy and someone would have to decide which one was right.

Something has to catch what gets through. No design removes every exception, so you need a way to see them fast. We’re still building this piece, but the plan is an exception report that compares what’s entered in each system of record and flags anything that doesn’t match, served up first thing in the morning for a quick triage. It stops a bad record from traveling any further, and it doubles as a feedback loop, since every flagged record points back to the step that created it and gives you something specific to train on or tighten up.

Down to the words you choose

One more piece of this that’s easy to miss: default versus design goes all the way down to vocabulary.

Early in one of my first leadership roles, at a print company, I kept seeing “RSP” on job tickets and travelers. It was everywhere. Weeks went by before I figured out it meant reverse side printing, because I was the new guy who was supposed to know the industry and I didn’t want to ask the dumb question. Everyone who’d been there a while knew exactly what it meant, which is precisely why nobody ever defined it.

Our client had the same thing spread across their systems, with terms and tags that weren’t consistent from one tool to the next and weren’t clear to anyone who hadn’t grown up with them. “Good enough, everybody knows what it means” is the default. Design is asking someone outside the process what they think a field or a status means, and fixing it when their answer doesn’t match yours. They don’t have to be from outside the company, just unfamiliar with the process.

“We don’t have that problem, that’s just data entry”

I can already hear the pushback, because it’s reasonable. You’ve got fires to put out, and a blank field inside one of your software tools doesn’t feel like one. This particular client stays on top of their receivables better than most, and bad debt was never their biggest leak.

This isn’t busywork. It’s the risk nobody sees until it bites. In the course of this work we found a path where a job could finish production and never get invoiced, because nothing between the two systems would catch it. It’s low probability, but it’s real money. Harvard Business Review published a study in 2017 where executives audited the critical fields on their department’s last 100 records, and on average 47% of newly created records had at least one critical error. Most leaders assume their data is better than that. Most haven’t checked.

I’d draw the line by system. If the tool touches money (your accounting system, your ERP, your MIS, WMS, etc.), blanks and stale defaults deserve a leader’s attention. If it’s a CRM or one of the more peripheral tools, the stakes are usually lower and it can wait its turn but tred cautiously since a missing name in your CRM can lose you an opportunity when someone receives a personalized email starting with “Hello <<NULL>>.”

How to run a blank field audit

This is crawl, walk, run, and every company’s version will look a little different. Here’s where I’d start.

Crawl: pick one field and get the real number. Start with payment terms and tax status. If you want a third, add credit limits. That one exposes risk, but not every company has them or wants them, so a blank there isn’t automatically wrong. Export your customer list, filter to active accounts, and count how many have the field empty. Then go create a test customer and a test invoice and save them without touching anything, so you can see what the system does on its own. Now you know your default and your total exposure.

Walk: decide what a blank should mean. Before you fix a single record, decide what the answer should be when nobody chooses, and make the default the safe answer. For most companies, that’s due on receipt, with terms as something a customer earns. Write the definition down somewhere people can actually find it, and give exceptions a real path so nobody has to invent a workaround at 2 a.m. Then do the cleanup, and warn your team ahead of time that the cleanup is going to look like it broke things.

Run: make the system catch the next one. Put the rule in the tool instead of in someone’s memory, and build a standing check, whether that’s a weekly export or a morning exception report, that shows you any new blank or mismatch while it’s still one record instead of 2,547.

Final Thoughts

Every default system is created through decision making. Most of those decisions were good ones, made by good people with the information they had at the time, and a lot of them are still running your business long after the reason for them went away.

Somebody chose net 30 for a reason. Nobody chose it for 2,547 customers.

Every default is a decision. The only question is whether it’s still yours.

That’s it for today.

See you all again next week!

Dave