Aug 25, 2026
A Two-Week Close Is a Process Problem, Not a Staffing One
Ask a finance lead why the close takes two weeks and the answer is usually about capacity. Not enough people, too many transactions, the team is stretched.
Sometimes that’s true. More often the close is long because of when the work happens rather than how much of it there is. Almost nothing starts until the period ends, so a fortnight of work that could have been spread across the month gets compressed into the fortnight after it.
Adding a person to a sequential process makes it slightly faster. Changing when the work happens makes it dramatically faster.
Where the two weeks actually go
A reasonably typical breakdown for a multi-channel e-commerce brand closing on a two-week cycle:
| Activity | Working days |
|---|---|
| Bank and payment processor reconciliation | 2.5 |
| Marketplace settlement reconciliation | 2.0 |
| Supplier invoice capture and coding | 1.5 |
| Inventory and cost of goods adjustments | 1.5 |
| Accruals and prepayments | 1.0 |
| Intercompany and other adjustments | 0.5 |
| Review and correction cycles | 1.5 |
| Reporting pack assembly | 1.5 |
| Total | 12 |
Yours will differ, but the shape usually holds: reconciliation is the largest block, document handling is the second, and reporting assembly consumes more than anyone expects.
The important observation isn’t the size of any block. It’s that the first six lines could all have happened during the month, and didn’t.
The sequencing trap
Here’s the structure that keeps closes long.
Reconciliation waits for the period to end. Coding waits for reconciliation. Cost of goods waits for coding. Accruals wait for cost of goods. Review waits for everything. Reporting waits for review.
Each step waits for the one before it, and the whole chain waits for the month to finish. So a close is the sum of its steps rather than the longest of them.
This is why hiring doesn’t fix it. Two people on a sequential chain mostly wait for each other. The fix is to break the dependency on period-end, not to add capacity at period-end.
What can move earlier
Most of it, in practice.
Reconciliation, continuously. There is no reason bank and processor transactions from the 3rd of the month need to wait until the 1st of the next to be matched. Run matching daily and by period-end you’re reconciling three days of transactions, not thirty. This alone typically removes the largest block in the table.
Document capture on arrival. A supplier invoice arriving on the 8th can be captured, extracted, validated, and coded on the 8th. The current pattern — invoices accumulating in an inbox until someone processes the batch — creates a peak at exactly the worst moment.
Marketplace settlements as they land. Settlements arrive on their own cycle, usually fortnightly. Decompose and match each one when it arrives rather than saving them up.
Recurring accruals on a schedule. Anything predictable — rent, subscriptions, known service costs — can post on a rule rather than being calculated fresh. The exceptions still need judgment; the routine ones don’t need to be rediscovered monthly.
Reporting that builds continuously. If the pack assembles from reconciled data, it exists in draft throughout the month and is reviewed at close rather than built at close. This is often the single most visible change, because it moves a day and a half of assembly work into something that happens on its own.
What has to stay at the end
Less than most teams assume, and it’s worth being precise about it, because the answer sets your floor.
- Cut-off decisions — which transactions belong to which period, at the boundary
- Judgmental accruals — estimates that genuinely require someone to think
- Exception resolution — the items automation flagged and couldn’t settle
- Final review — someone senior looking at the whole thing
- Sign-off
That’s typically two to three days of work, not twelve. If your genuine period-end-only tasks come to more than three days, that’s worth examining separately — it usually means something is being reconstructed at close that could have been recorded during the month.
Ownership and status
Two changes that cost nothing and shorten closes more reliably than most software.
Every exception queue has a named owner. The most common hidden delay isn’t work being slow, it’s work sitting in a queue everyone assumes someone else is watching. An unmatched transaction from the 6th that nobody owns is discovered on the 2nd of the following month and now blocks the close.
The close has a visible status. “Is the close done?” should be answerable by looking, not by asking. A simple board showing each step, its owner, and its state removes an entire category of chase-up, and — more usefully — makes the bottleneck obvious rather than anecdotal. Most teams discover their bottleneck is not where they assumed.
A close-timing audit
Do this for one month. It takes about twenty minutes of logging per day and it will tell you more than any general advice, including this article.
For each activity, record three things:
| Activity | Days spent | Could it have run during the month? | What blocks it from running earlier? |
|---|---|---|---|
| Bank reconciliation | Y / N | ||
| Processor reconciliation | Y / N | ||
| Marketplace settlements | Y / N | ||
| Supplier invoice capture | Y / N | ||
| Coding and classification | Y / N | ||
| Inventory / COGS | Y / N | ||
| Accruals and prepayments | Y / N | ||
| Review cycles | Y / N | ||
| Reporting assembly | Y / N |
Then sort by days spent, descending, and look only at the rows marked Y.
The top one is your project. Not the whole close, not a new system — the single largest block of work that had no structural reason to wait for period-end. For most e-commerce brands that row is reconciliation, and moving it alone takes a fortnight down to about a week.
The third column matters as much as the second. “What blocks it from running earlier” is usually one of three answers: the data isn’t available until later (rarely true, worth checking), the tooling only runs in batch (fixable), or nobody has ever tried (most common).
What three days looks like
For that to be the close, several things have to be true:
- Transactions are matched daily, so period-end reconciliation covers days rather than weeks
- Documents are captured and coded on arrival
- Coding is rule-based and consistent, so review is spot-checking rather than re-deciding
- Exceptions have owners and are cleared continuously
- The reporting pack assembles itself and is reviewed rather than built
None of these individually is dramatic. Together they change the close from a reconstruction into a confirmation — and confirmation is fast, because the work was already done.
The honest caveat: getting there takes a quarter or two, and the first month is slower, not faster, because you’re running the new process alongside the old one. That’s the actual cost, and it’s worth knowing before you start rather than discovering it in month one.
Financial Operations puts close, reconciliation, and reporting on one automated rhythm with named ownership and audit trails. AI Reconciliation is what makes continuous matching possible.
Contact us today to talk through a close-timing audit on your own process.
Related Blogs
See All Blogs
The True Cost of a Product Isn't What You Paid For It
Ask most e-commerce operators their gross margin and you'll get an answer immediately. Ask what's in the cost side of that calculation and...
Why Your Marketplace Payouts Never Match Your Sales Report
Your sales report says one number. Your bank says another. The difference is large, it changes every period, and nobody can explain it in a...
The Problem with Invoice Automation
Every invoice automation demo goes the same way. A clean PDF, a confident extraction, fields populated correctly, a number like 99% accuracy...
Reliable Numbers, Less Manual Work
We connect your systems and automate the repetitive financial work — consolidating data, reconciling transactions, and extracting it from documents — so accurate numbers reach your tools without the manual effort.
