Payment Run Cutoff Exception Log

Set the cutoff as a timestamped gate

A payment run cutoff is not a date on a calendar. It is a specific time, in a named time zone, after which new invoices and changes do not enter the current file. Publish the time, the systems that close, the approver who must act before it, and the channel for a true emergency.

Record the cutoff time actually applied, not the planned time. If the run opened late or a system was unavailable, write that down. The log should let a reviewer reconstruct which items could have entered the run and which could not.

Publish the cutoff in the same calendar the approvers use and state whether it moves for a bank holiday. A cutoff that shifts without notice trains people to treat the deadline as optional, which then shows up as a late-approval exception every cycle.

Capture the exception when it appears

Log the item at the moment it becomes at risk, not after the run closes. Record the invoice or payment identifier, supplier, amount, currency, entity, required approver, missing item, first seen time, and the person who noticed it. A late entry created the next morning loses the sequence.

Link the evidence that exists. That may be the approval request, the receipt search, the bank verification ticket, or the supplier message. If no evidence exists, say so. The log is a record of the state at cutoff, not a place to assemble a case after the fact.

Use one intake point for exceptions so a message in chat does not become an invisible case. If someone reports a problem by phone, the person who takes the call should create the log entry and read the key fields back to the caller.

Classify late approval, missing evidence, and bank holds

Use a small set of causes: approval not received, receipt or PO missing, invoice data incomplete, vendor master or bank change pending, tax document missing, duplicate or fraud review open, and treasury or bank constraint. The cause determines who can resolve it and whether the item can be paid at all.

Do not use a single late category for everything. A late approval is an authority issue, a missing receipt is a receiving issue, and a bank hold is a settlement issue. Combining them hides the owner and makes the weekly review repeat the same conversation without a decision.

Decide carry, hold, or cancel

Every exception needs a disposition before the file is released. Carry means the item is complete but missed the cutoff and should enter the next run. Hold means evidence is still missing and the item needs a dated follow-up. Cancel means the invoice should not be paid, for example because it is a duplicate or was credited.

Name the decision owner. AP can recommend a disposition and prepare the evidence; the finance or treasury owner approves payment-affecting choices. Record the decision time so the next run can verify that a carried item was actually included.

A carried item should not be automatically paid in the next run. Check that the missing condition is now satisfied and that the amount has not changed. Revalidate the supplier and bank details if the delay was caused by a master-data question.

Give treasury a clean proposal

The proposal should separate clean items, carried items, and held items. For each carried item, show why it missed the cutoff and what has changed since. Treasury should not have to read the exception log to understand the file.

Reconcile the proposal total to the approved invoice list and the payment file. Investigate differences before release. A file that balances to itself but not to the approved list can still pay the wrong amount.

Record the next-run commitment

For each carried item, record the next run date and the condition that must be met. If the item depends on a supplier document, name the request date and the expected response. If it depends on an internal approver, name the person and the escalation path.

Do not let carried items disappear into the next cycle without a check. At the next cutoff, compare the carry list to the new proposal and record which items entered, which slipped again, and why. Repeated slippage is a process finding, not just a busy week.

Review cutoff pressure weekly

Report the number of exceptions, the amount, the causes, the owners, and the share that carried. Compare the current week with the prior four weeks. A rising carry rate near month end may indicate an approval bottleneck rather than a staffing shortage.

Sample a few exceptions and confirm that the cause code and disposition were correct. If approvers routinely act after the cutoff, the fix may be a reminder schedule or a changed approval deadline, not more AP overtime.

Test the log with a mock run

Run a tabletop exercise with a small set of synthetic invoices: one missing receipt, one approval after cutoff, one bank change under verification, and one duplicate alert. Ask each participant to log the item and propose a disposition.

Check that the timestamps, owners, and evidence links are complete and that the proposal separates clean from carried items. Fix the template before the next live run. A log that only works in a quiet week is not a control.

Invite treasury, AP, and the approver group to the exercise. The disagreements are the useful output, because they show where the written cutoff rule and the practical routine have drifted apart.

Close the run with a signed summary

After the file is released, record the run date, cutoff applied, file reference, total amount, item count, exceptions, and dispositions. The preparer and the reviewer should sign or otherwise acknowledge the summary.

Keep the summary with the payment file and the exception log. If a supplier later asks why an invoice was not paid, the team can answer from the record instead of reconstructing the week from messages.

Store the summary where treasury and AP can both reach it, and link it to the exception log rather than duplicating the detail. The next run review can then compare the carry list with the new proposal without rebuilding the history.