Most mid-market finance teams do not lack a general ledger. They lack a view of cash that matches how money actually moves: invoices in, collections in, and scheduled payments out.

An ERP can wait. Cash cannot. Before you scope a system, get the three lists you already own onto one screen.

• Payables waiting on an approval, with a due date and an owner.
• Receivables waiting on a customer, with an expected collect date.
• The next payment run, with the amount that will actually leave the account.

Those three lists describe most of the cash story at a company doing two to fifty million in revenue. Put them side by side and the gaps show up on their own: a large vendor payment sitting in the same week as a slow customer.

Visibility is not a dashboard

A dashboard shows you numbers. Visibility means you can answer a question without asking anyone. Those are different standards, and only the second one changes how the week runs.

The test is simple. On a Tuesday afternoon, can you say what leaves the account on Friday, who approved it, and what is expected to land before then? If that takes more than a minute, you do not have visibility. You have a report.

Cash in the bank is a snapshot

The balance tells you where you have been. Open invoices and scheduled payments tell you where you are going. Controllers need both, and they need them on the same screen, because the interesting decisions live in the overlap.

Skip vanity totals. Lifetime revenue and total invoices processed do not help anyone decide whether to release a payment batch. Show what is due, what is approved, and what is still waiting on a person.

Order payables by due date

Not by amount, not by who entered it, and not by whoever last opened the file. Due date is the only sort order that matches how cash actually leaves.

Order receivables by expected collect date

Even when that date is a judgment call. A judgment you can see is more useful than a term you know the customer ignores. Write down the date you actually expect, then track how often you were right.

You do not need a new ledger to do this

The books can stay exactly where they are. Operations software sits next to them and tracks the work that happens before a journal entry exists: the invoice arriving, the approval landing, the payment being scheduled.

If your accountant posts in an older system, that is fine. They need a cleaner feed, not a second close. The worst outcome is two systems that both claim to be the record, which is what happens when a finance team tries to make the ledger do operations work.

The weekly cash huddle

Once a week, look at what is approved to pay, what is still stuck, and which customers are late. Thirty minutes. The same three lists every time.

Write the decisions in the same tool you used to make them. If the huddle lives in slides, you will rebuild the slides every week, and the decisions will live in someone's memory until they leave.

Name one owner for payables and one for collections. Hold a payment batch until the payables owner confirms the cash week can take it. Record late customers as work with a next action, not as a surprise that shows up in the forecast.

Why spreadsheets fail this job quietly

A cash model in a workbook goes stale the moment an invoice is approved off-sheet. Version names pile up. Nobody is sure which file the controller used on Friday, and the honest answer is usually that they used a copy.

The failure is quiet, which is what makes it expensive. The workbook still opens. The formulas still calculate. It just describes a company you were running two weeks ago.

The fix is not a better workbook. It is making the queue the model, so the numbers move when the work moves.

The three numbers to know on a Monday

If you want one habit rather than a project, start here. Every Monday morning, know three numbers before anyone asks.

The first is what is committed out over the next fourteen days. Not what might be billed, but what has been approved and will leave the account unless somebody holds it. This number is knowable and most teams cannot state it.

The second is what you expect in over the same window, using the dates you actually believe rather than the terms on the invoice. If a customer has paid at fifty days for two years, thirty days is not an expectation. It is a hope.

The third is the gap, and whether the gap is covered. That is the only one anyone will ask you about, and it is the one you cannot produce on demand if the first two live in a workbook.

What to do when the answer is uncomfortable

Visibility is only useful if something can change once you have it. When the fourteen-day view shows a gap, you have four levers and they are all operational.

You can move a payment run, which costs you goodwill with specific vendors and should therefore be a named decision rather than a silent delay. You can chase specific receivables, which works better when you already know who is late and why. You can split a batch so the critical vendors clear and the flexible ones wait. Or you can decide the gap is fine because a known deposit lands on the fifteenth.

All four require the same thing: a list you trust, early enough to act on. A month-end report gives you none of those options, because by the time it exists the week already happened.

Control as the cash board

Control shows payables, receivables, and a forecast built from those queues. It is not a bank and it does not replace your ledger. It gives finance a working view before month-end, which is the part a ledger was never designed to do.

If you still close in an older system, bring the queues into Control first and leave the close alone. The close gets quieter on its own once the week is already visible.

• Put payables, receivables, and the next payment batch on one board.
• Run the weekly huddle from that board instead of a rebuilt slide.
• Record the expected collect date, then check it against what happened.
• Leave banking and lending to the bank, and keep the operations view in Control.