payment run preparation checklist
A payment run preparation checklist gives the release owner a reviewable set of proposed payments without handing release authority to the preparer. Each line should point to the approved invoice, due date, approval evidence, payee record, payment method status, and any open exception. The preparer assembles and checks the packet. An authorized person decides whether the payment run can be released.
The checklist is most useful when it catches uncertainty before anyone reaches the bank or payment platform. It should make a missing approval, changed bank detail, suspected duplicate, or unmatched credit visible. A tidy total is not enough if the support behind it cannot be followed.
Set the run boundary before collecting invoices
Start with a named payment cycle. Record the covered entities, bank accounts or approved payment methods, invoice cutoff, proposed payment date, preparer, reviewer, and release owner. These are operating choices set by the business. They should not be reconstructed from last week's habits.
Define what qualifies an obligation to enter the run. For example, the written procedure may require an approved invoice in the payable system, a matched supplier record, a due date within the cycle, and evidence of the required business approval. The exact rules depend on the organization's policy. A coordinator should apply the documented rule and route anything outside it.
Keep the candidate population visible. If the process starts from an accounts payable report, preserve the report date, filters, entity, and source reference. If items are added manually, record who requested the addition and why it did not appear in the normal source. That prevents a late message from slipping into the run without the same checks as every other payment.
An invoice cutoff is not the same as a release deadline. The cutoff says when normal preparation closes. The release deadline belongs to the authorized owner and payment calendar. When an urgent request arrives after cutoff, flag it as an exception rather than quietly changing the run boundary.
Build one traceable line for each proposed payment
A reviewer should be able to move from a checklist line to the current approved record. Use stable system references instead of copying whole invoices or sensitive banking details into a spreadsheet with weaker access controls. Where the checklist displays a value, identify its approved source.
| Checklist field | What the preparer records | Stop and route when |
|---|---|---|
| Supplier and invoice reference | The identifiers shown in the payable system | The supplier or invoice cannot be matched confidently |
| Amount and currency | The values on the approved payable record | Supporting records disagree |
| Due date and proposed date | The source due date and planned cycle date | Timing requires an exception or policy decision |
| Approval evidence | A reference to the recorded approval | Approval is missing, unclear, or outside the approved path |
| Payment method status | The status shown in the controlled supplier record | Details changed or arrived through an unapproved channel |
| Exception owner | The person authorized to resolve the exact issue | No accountable owner is named |
Avoid statuses such as "checked" unless the procedure defines what was checked and against which source. A useful status describes an observable point: candidate identified, support present, exception open, ready for review, returned for correction, approved for release, or removed with a recorded reason.
Do not let free text carry the whole process. Notes are appropriate for the exact conflict or question. They are a poor substitute for a due date, owner, source reference, or exception type that a reviewer needs to sort.
Check duplicates, changes, and credits separately
Duplicate risk deserves its own check because two different records can look legitimate in isolation. Compare the approved duplicate-detection fields established by the finance team, which may include supplier, invoice identifier, amount, date, purchase reference, or prior payment record. A possible match is a reason to stop and investigate. It is not permission for the preparer to delete or merge records without authority.
Treat supplier payment-detail changes as a distinct exception. The payment run is too late to invent a verification method. The organization should define an approved change process, safe communication channels, evidence requirements, and authorized reviewers before a change reaches the queue. The preparer can confirm that the recorded process was followed. The preparer should not decide that an email is trustworthy or replace controlled details based on an informal message.
Credits and offsets also need an explicit disposition. A visible credit may affect the proposed amount, but how it applies can require accounting judgment or supplier communication. Record the credit reference and route the decision. Do not hide it in a note or adjust the proposed payment merely to make the checklist balance.
These checks are easier when supplier records, invoices, approvals, and payment history have stable identifiers. If staff must search several inboxes for every line, improve the source process before increasing payment-run volume.
Reconcile the packet before reviewer handoff
Reconcile the checklist total to the proposed batch total from the payment system. Break totals out by entity, currency, and payment method where those distinctions affect review. Record the time of the comparison because the source may change after the preparer exports it.
The reconciliation should explain every difference. An excluded invoice needs a reason. A late addition needs its source and approval path. A returned item should remain visible with its disposition so the reviewer can understand how the starting population became the proposed batch. Deleting awkward rows creates a cleaner spreadsheet and a weaker audit trail.
Review sequencing as well as totals. Confirm that the proposed date follows the approved calendar and that items marked urgent have a recorded exception. Look for unusually old open items, repeated returns, and payments waiting on the same owner. These views help the finance manager find process problems without asking the preparer to make accounting or cash-management decisions.
The IRS guidance on business records explains that a recordkeeping system should clearly show business income and expenses and discusses supporting documents and transaction records. It does not prescribe an organization's payment approval design. Finance, accounting, tax, legal, security, and banking requirements should be set by the responsible professionals.
Make the review and release handoff explicit
Send the reviewer a fixed candidate version, not a live sheet that can change silently during review. Record the run identifier, preparation timestamp, total, exception count, preparer, and source references. If someone changes the candidate after review begins, identify the changed lines and require the review step defined by policy.
The review result should be recorded in the approved system. A chat reaction or verbal answer is hard for the next person to verify. If the reviewer returns a line, capture the reason and the next owner. If the reviewer accepts an exception, point to the authorized decision rather than rewriting the exception as if it never occurred.
Separate review from release. The person who verifies preparation may or may not be allowed to release funds. The checklist should name the release owner and show the evidence that the run reached the approved state. It should never contain credentials, authentication codes, or other secrets.
After release, record the system result and route failures. A rejected or returned payment is new work with its own owner and evidence. Do not change the pre-release checklist to make it appear that the failed item was never included.
Test the checklist with difficult cases
Pilot the procedure with more than clean invoices. Include a possible duplicate, a changed payment detail, a partial approval, a credit, a late request, an invoice for the wrong entity, and an item returned by the payment platform. For each case, ask the preparer to show the source used and the written rule that supports the next action.
Give the draft run to a trained backup without an oral briefing. The backup should be able to identify the source population, open exceptions, last verified action, next owner, reconciliation status, and reviewer. If the backup must rely on private messages or memory, the handoff is not ready.
Sample completed runs against the payable system and recorded decisions. Classify corrections by cause, such as missing source data, transcription, wrong entity, late approval, duplicate handling, or unclear procedure. Review the cause rather than using a single error percentage to describe the entire process.
Track elapsed time separately from active preparation time. Elapsed time includes waits for approvers and suppliers. Preparation time helps estimate recurring administrative effort. Exception age and reviewer time can show whether delay comes from workload, unclear ownership, or a policy that needs revision.
Delegate preparation without delegating authority
Payment-run preparation can be assigned as recurring back-office work when the intake source, field definitions, access limits, stopping rules, reviewers, and release boundary are documented. Start with one entity or payment method and schedule close review. Expand only after ordinary and difficult cases leave a trace another trained person can follow.
Give the coordinator worked examples, safe handling instructions, approved messages, escalation contacts, backup steps, and access-removal procedures. Prohibit shared credentials. Review permissions when the role changes and after the assignment ends. The virtual assistant access checklist can help structure that access discussion.
HireBackOffice bookkeeping assistant support can help scope recurring invoice assembly, follow up, and payment-run preparation once decision rights remain with your finance team. Document management support may be relevant when approvals and invoice files lack a controlled home. Contact HireBackOffice with anonymized examples, approximate run volume, systems involved, and the decisions your team retains. This article provides general operational information, not legal, tax, accounting, banking, or security advice.