Every Controller we talk to has a version of the same complaint: close week starts on the first business day of the month and ends sometime around day ten — if they're lucky. The official story is that the close takes nine to twelve days because it has to: journal entries, accruals, inter-company reconciliations, financial statement prep. That's the narrative finance teams tell their CFOs.
The more honest accounting: a substantial chunk of those nine days is reclassification work — hunting down transactions that landed in the wrong GL account, correcting cost center assignments, chasing department heads for coding confirmation, and re-running trial balance comparisons after each correction batch. It's not glamorous and it's rarely tracked as a discrete activity, which is exactly why it persists.
What Actually Happens During Close Week
We built Spendaq specifically because Yuki, our founder, spent six years as a Controller watching this pattern repeat. So when we started talking to other Controllers and finance ops managers in early 2024, we weren't asking whether GL miscoding was a problem — we knew it was. We were trying to understand the magnitude.
The picture that emerged was consistent: in companies running 500–3,000 transactions per month (a typical range for mid-market companies in manufacturing, professional services, or distribution), between 25% and 35% of transactions require some form of post-ingestion correction before the books can close. That correction work takes two forms:
- Active reclassification — a transaction was auto-coded by the ERP to account
7200 Office Supplieswhen it should be7410 Software Subscriptions. Someone has to catch it, create a journal entry, get it approved. - Passive hunting — nobody flags the error in real time. The Controller runs the P&L against budget variance and sees an anomaly in operating expenses. She traces it back through the detail ledger, finds three Zoom invoices that landed in
6100 Telephoneinstead of7410, and now it's day six and she's still doing clean-up work that should have been done at ingestion.
The passive hunting variant is worse because the error compounds. By the time a miscoded transaction surfaces in a variance analysis, it's affected budget comparisons, cost center reports, and potentially inter-company allocations if those transactions flow through subsidiary entities.
Why ERPs Systematically Underperform on Categorization
This isn't a criticism of any specific ERP vendor. QuickBooks, NetSuite, Sage Intacct — they're all built around a fundamentally different assumption about how transactions arrive: that someone with accounting knowledge is coding each transaction at the point of entry. The categorization logic that exists in most ERPs was designed as a convenience layer on top of that human judgment, not a replacement for it.
The problem is that by 2025, most corporate transactions are arriving through automated feeds — corporate card platforms pushing data via API, bank feed integrations pulling ACH and wire detail, AP automation tools processing invoice batches. These feeds carry vendor names in raw format: AMZN MKTP US*1K8J3, UNITEDAIRLINES.COM, ZOOM.US 855-799-1189. The ERP's mapping rules were almost certainly written when those vendor strings looked different, or weren't written at all for new vendors.
We benchmarked auto-categorization accuracy across several ERP configurations in our early customer work. The pattern: out-of-the-box auto-categorization hits 60–70% accuracy on transaction descriptions. That sounds acceptable until you do the math on a 1,500-transaction month: 450–600 transactions requiring manual review or correction. At four minutes per transaction (find, assess, reclassify, document), that's 30–40 staff hours of pure reclassification work every single month-end close.
The Journal Entry Backlog Problem
What makes this worse is that GL miscoding doesn't create a simple correction task — it creates a journal entry backlog that has its own approval chain. At most companies, journal entries above a certain dollar threshold require dual approval. A batch of 50 reclassification entries sitting in the approval queue at day seven of close is a bottleneck that has nothing to do with accounting accuracy and everything to do with how long it takes to move corrections through the workflow.
Consider a plausible scenario: a Charlotte-area building materials distributor with roughly $80M in revenue runs about 2,200 transactions through their NetSuite instance per month — card charges, ACH vendor payments, wire transfers, and AP invoice lines. Their ERP auto-categorizes using rules set up during the original implementation in 2019. Since then, they've added a fleet fuel card program, migrated from Concur to Ramp for travel, and started paying four new SaaS vendors. Their mapping rules haven't kept up. Come close week, the Controller's team is correcting roughly 500 transactions — mostly the new card programs, the SaaS vendors, and anything touching the two new product lines they added in 2022. Three staff members spend about 12 hours each on reclassification during close week. That's 36 hours that aren't being spent on variance analysis, forecast updates, or any forward-looking work.
What "Fixing It" Usually Looks Like (And Why It Doesn't Work)
The standard response is to improve the ERP mapping rules. And it helps — for about three months. Then a new vendor arrives, or someone runs a one-time marketing spend through an unfamiliar account, or the company acquires a small division whose chart of accounts uses a different numbering convention. The rules degrade.
The other common fix is to assign a junior accountant specifically to the categorization review queue during close week. This works as a band-aid: the errors get caught and corrected. But you've now institutionalized an error-correction role as a permanent part of your close process, which means the underlying miscoding isn't actually a problem anymore in anyone's mind — it's just "how close week works."
We're not saying that improving ERP mapping rules is wasted effort. Accurate rules reduce the noise. But rules-based systems degrade because corporate spend patterns change continuously, and rules require manual maintenance to stay current. The fundamental issue is that static rules can't keep pace with the entropy of real-world transaction data.
The Categorization Accuracy Floor and What Breaks Through It
The accuracy ceiling for rules-based categorization is somewhere around 70–75% on production transaction data in a mid-market company with normal vendor churn. Getting above that floor requires something that can generalize — that can recognize that ADOBE*INCADOBE and ADOBE SYSTEMS INC are the same vendor, that a charge from a hotel with a per-diem range consistent with a recent business trip should code to 7302 Travel - Lodging even if the hotel's merchant descriptor has never appeared before.
This is what we built Spendaq to address. The engine we use trains on your actual chart of accounts and transaction history — not a generic taxonomy. It learns that in your specific account structure, AWS charges go to 6550 Cloud Infrastructure, not 7410 Software Subscriptions, even though both would be reasonable for a generic classifier. It learns your cost center allocation patterns, your vendor aliases, your departmental spend signatures.
The result, in the first accounts we onboarded, was categorization accuracy in the 95–98% range — meaning the volume of transactions requiring human review dropped from 30%+ to under 5%. That shift in review queue size is what changes close week from a reclassification marathon to a brief exception-handling session.
How This Changes the Close Timeline
When categorization accuracy runs near 98%, the close process changes structurally. The journal entry backlog from reclassifications largely disappears. The variance analysis the Controller runs on day two actually reflects accurate account balances — she's not chasing phantom variances caused by coding errors. Department heads stop getting pinged for confirmation on miscoded expenses because fewer expenses are miscoded in the first place.
The time saving is real, but the more meaningful change is where the Controller's attention goes. When reclassification is a two-hour exception review instead of a three-day correction sprint, the Controller has time to do the forward-looking analysis that the close is supposed to enable: comparing actuals to budget, identifying cost trends, building the forecast inputs the CFO needs. That's the work that requires accounting judgment. Fixing AMZN MKTP routing errors is not.
If your current close timeline looks like ours used to — nine to twelve days, with a significant portion of that in reclassification work — the problem almost certainly starts at categorization. The journal entry backlog, the approval delays, the variance hunting: those are symptoms. The root is that your transaction data is arriving miscoded and staying miscoded until someone catches it manually.
That's the problem we're built to solve. Not by adding another step to the close process, but by fixing the categorization layer before the books ever open for close review.