A payment schedule is a promise, and most finance teams break theirs by accident.

Not because anyone decided to pay late. Because the due date lived in one place, the approval lived in another, and the cash decision happened on a Friday when the person who knew both was out.

Start from terms you can actually see

Before you schedule anything, the vendor record has to carry the terms. Net 30, net 45, due on receipt, two percent ten net thirty, whatever you agreed. If the terms only exist in a signed PDF in a shared drive, they are not operational.

• Payment terms, written the way the vendor states them.
• Preferred method, and the date that method actually clears.
• Remit-to details, with a note on when they were last confirmed.
• Whether an early payment discount exists and whether you have ever taken it.

Confirm banking changes out of band

If a vendor emails to change bank details, confirm by calling the number you already had on file. Not the number in the email. This is the cheapest control in payables and the one most often skipped.

Build the schedule from approved invoices only

An invoice that has not been approved is not a scheduled payment. It is a forecast. Keeping those two things separate is what makes the schedule trustworthy.

The schedule should answer one question on sight: what leaves the account, on what date, to whom. Everything else is context.

• Group payments into runs on fixed days so the team knows when to look.
• Show the run total next to the cash position for that week.
• Let a single line be held without holding the entire run.
• Keep held items visible in the run, greyed out, with a reason.

Fixed run days beat continuous payment

Paying whenever an invoice is approved feels responsive and makes cash unpredictable. Two runs a week is usually enough. Vendors learn the rhythm and stop calling.

Decide early payment on purpose

Discounts are real money, and they are also a cash decision. Two percent ten net thirty is worth taking when you have coverage and worth skipping when you do not. The point is that someone decided.

Put the discount deadline on the invoice so the choice is visible while there is still time to make it. A discount you missed because nobody saw the date is not a decision. It is a leak.

Recurring bills need their own handling

Rent, insurance, software subscriptions, and utilities behave differently from vendor invoices, and treating them the same way is how they end up unreviewed for three years.

They are predictable, which is useful for forecasting and dangerous for oversight. A recurring payment that runs on autopilot will keep running after the contract ends, after the headcount it was sized for left, and after the price went up twice.

• Mark recurring payments so they are visible as a group, not buried in the run.
• Record the renewal or review date on the vendor, not in someone's calendar.
• Route a price increase above a set percentage to a person, automatically.
• Review the whole recurring list once a quarter, out loud, with the owner present.

Predictable is not the same as approved

A recurring payment still needs an owner. The difference is that the owner reviews the arrangement rather than each invoice, which is a reasonable trade as long as the review actually happens.

When cash is short

Every schedule eventually meets a week that cannot take it. What separates a controlled response from a scramble is whether the decision is made in advance and written down.

Rank the run before you need to. Payroll-adjacent obligations and anything with a service interruption attached sit at the top. Vendors with a relationship worth protecting sit next. Flexible suppliers who have told you they do not mind a week come last, and it is worth knowing which of your vendors those are before you need the answer.

Then tell people. A vendor who gets a call on the eighteenth saying the payment moves to the twenty-sixth is a vendor you can call again. A vendor who finds out by checking their bank is a vendor who tightens your terms.

Match the run back to the bank

The schedule is only trustworthy if you close the loop. Every scheduled payment should end up matched to a bank line, and the ones that do not should be obvious the next morning.

• Match on amount and date first, then on vendor.
• Flag partial payments rather than closing the invoice.
• Investigate anything unmatched after two business days.
• Close the invoice only when the bank line and the schedule agree.

Unmatched is a status, not an error

Treat it as work with an owner. An unmatched payment that sits for three weeks becomes a reconciliation problem at close, and close is the worst time to investigate anything.

What controllers actually check

When a controller says a schedule is trustworthy, they usually mean four specific things, and none of them are about the software.

• Nothing gets paid without an approval on the record.
• The next two runs are visible with real totals, not estimates.
• Holds have a reason and an owner, so they do not become permanent.
• Last month's runs all reconcile to the bank without a side spreadsheet.

Where Control fits

Control keeps vendor terms, approved invoices, and payment runs on the same record, then matches those runs against bank activity so the loop closes on its own. Capvolta is not a bank and does not move money itself. Payments run through licensed processors.

The version of this that works is unglamorous. Terms on file, approvals recorded, runs on fixed days, bank lines matched within two days. Do that for a quarter and the schedule stops being a promise you hope to keep. It becomes the thing your vendors plan around, which is the whole point.