Contractor payment reconciliation: a monthly close checklist

A contractor payment is ready for close when finance can explain the approved amount, the payment instruction, the movement of cash, and the accounting entry. A bank debit alone doesn't answer all four questions.

Download the monthly close checklist and workbook instructions. Use the separate source tabs linked below to preserve each record's grain and avoid double-counting.

The difficulty grows when hundreds of work items become one contractor payment, several payments share a funding debit, and a return arrives after month-end. Matching by name and amount leaves too much room for error. The practical fix is a repeatable reconciliation built around stable IDs, separate dates, and an owned exception queue.

This checklist is for controllers and finance operations teams paying recurring contractor networks. Use it to establish the evidence your close needs, then adapt the entries and cutoffs with your accounting adviser. The examples are illustrative USD transactions, not customer data or prescribed accounting treatment.

Establish the records you're trying to match#

Start with one payer entity, currency, and accounting period. Reconcile those separately before rolling them up. Two entities can pay the same contractor without sharing a payable balance, bank account, or reporting responsibility.

Your payment platform and general ledger may describe the same activity differently. Write down what each record represents before comparing totals.

Don't force a one-to-one match where the workflow is one-to-many. A $1,200 payment could cover four $300 work orders. A $20,000 funding debit could support several payout batches and leave money unused. Keep allocation records so the relationship is explicit.

If approved amounts cannot be reproduced, start with the timesheet-to-approval workflow before reconciling cash. Retain the system's original identifiers alongside your reporting IDs. A display name is useful for review, but a changed business name should not break the connection to last month's record.

Freeze the close population and preserve later events#

Record the extraction timestamp, reporting timezone, entity, date filters, and status filters for every file. Keep an unchanged copy of each source export. A report rerun after a payment returns can show a different answer from the file used at close.

Use separate dates for work performed, approval, payment initiation, platform status changes, and bank posting. Your controller should choose the date and evidence used for each accounting treatment. A payment initiated on the final day of the month may post to the bank in the following period.

For status fields, retain the source label and a documented mapping. Treat labels such as submitted, processing, paid, settled, failed, and returned as provider-specific. Ask what event produces each label and what evidence supports recipient receipt. A platform's paid status should not automatically become a claim that the contractor's bank has credited funds.

When a late event changes an earlier payment, add it to the exception queue with both the event date and original payment date. Preserve the previously approved close and follow your policy for adjustments or reopening a period.

Reconcile the obligation before the cash#

Start with a payable roll-forward. In a simple example, opening unpaid obligations plus newly approved amounts, less approved credits and extinguished obligations, equals closing unpaid obligations. Your accounting policy determines when an obligation is treated as extinguished and how a returned payment reopens it.

Inspect unmatched payables before investigating differences in cash. Common causes include a work item approved after the export, a payment allocated to the wrong entity, or an adjustment applied directly to the payment file without updating the payable record.

The $39,000 line is a policy-dependent amount, not a synonym for instructions submitted. Investigate whether failed or returned attempts still sit inside it. A retry is another attempt to pay the same obligation; it does not create another expense.

Keep authorized deductions, reimbursements, and withholding in separately identified fields when applicable. Their accounting and tax treatment can differ. Don't hide every difference inside a net payment total.

Build a cash bridge for each funding model#

A direct-debit payment model and a prefunded balance need different reconciliations. Identify which model you use before building the workbook.

For a prefunded balance, match bank transfers into the platform to funding records. Then reconcile the opening balance, additions, payout debits, returned funds, fees, withdrawals, and closing balance. Distinguish total balance from funds currently available for release if the platform tracks reserves or pending availability.

Here is a simple balance bridge. Every movement in this example has posted by the cutoff, and no reserves, FX, withholding, or pending adjustments are included.

The $39,500 of payout debits less $500 returned produces $39,000 of net payout cash movement. That happens to match the obligation reduction in this example. In your books, differences can be legitimate timing items and still require evidence.

A bank debit of $40,000 therefore does not establish $40,000 of contractor expense or completed payouts. Some funding remains in the platform. Your controller must approve the account classification and journal treatment for that balance.

If fees are debited separately from your bank, exclude them from the platform balance bridge and reconcile them on the bank side. If a provider nets fees from another movement, retain a gross-to-net schedule. Use the actual fee statement, not the unexplained difference between two exports.

Match the general ledger without duplicating expense#

Determine which system creates the payable or expense entry and which system records payment. A work system might send approved obligations to the ERP while the payment platform sends settlement records. If both integrations create an expense, cash can reconcile while costs are overstated.

Test a completed payment through the full chain. Confirm the expense or liability entry, the cash or clearing entry, any fees, and the closing balance in the relevant clearing account. Finance should also be able to reverse the test: select a GL line and find its source evidence.

Use control totals by entity, currency, account, and period. Then inspect record-level differences. A matching total can conceal one omitted payment and another duplicated payment of the same amount.

Set a policy for rounding and permitted variances. A tolerance is a documented rule for a defined difference. It should not become a general permission to write off unexplained balances.

Give every exception an owner and a next action#

Keep exceptions outside the matched population until their treatment is approved. Use the payment reporting specification to carry those items into the daily action queue without mixing them with completed-period metrics. The queue should distinguish timing differences from errors, and errors from records that are simply missing evidence.

Escalation should depend on impact as well as age. A suspected duplicate release needs attention before the next payment run. An explained timing item can remain open with an expected clearing date. Neither should disappear because someone marked the spreadsheet reviewed.

Run the monthly close checklist#

Use the reconciliation CSV templates as separate workbook tabs: payables, payment allocations, payment attempts, cash movements, and GL lines. Add the record relationships, match dispositions, and exception queue, then use the illustrative balance bridge to check the structure. The workbook instructions define the grain and key for payables, allocations, attempts, cash movements, and GL lines. Relationship and match tabs contain IDs rather than repeated financial amounts. Calculate totals in each source tab before linking records; summing a many-to-many joined table can multiply the same payment. The sample balance bridge is labeled illustrative, and the input templates are blank. Import IDs as text so spreadsheet software doesn't change them. Keep bank credentials and full tax identifiers out of the workbook.

1. Confirm payer entities, accounts, currencies, reporting period, and approved accounting policies.
2. Save source exports with extraction timestamps and filters.
3. Reconcile the opening and closing payable population, including credits and returns.
4. Match payment allocations and attempts without counting retries twice.
5. Complete the bank and platform balance bridges, including fees and pending items.
6. Match source records to GL lines and review clearing-account balances.
7. Assign unmatched records, document proposed treatment, and obtain approval.
8. Save the reviewed workbook, supporting statements, journals, and open-item carryforward.

For filing-season aggregation across payment systems, continue with the year-end recipient reconciliation checklist. Monthly close evidence supports that review, but accounting totals do not determine reportable compensation by themselves.

Name a preparer and a reviewer. Where a small team cannot separate every activity, document the compensating review of payment changes, releases, and reconciliations. Decide who can reopen a completed period before a late return forces that decision.

Evaluate software against your hardest reconciliation#

For a US business whose services depend on a large recurring contractor network, we recommend evaluating Wingspan when the central need is to keep work, approvals, payments, and tax records connected. Our worker payments workflow retains source work and payment context. Validate the exact exports and accounting handoffs your close requires.

Safeguard Properties used Wingspan to consolidate payments across contractor codes. That is relevant to a many-to-one reconciliation design; the case does not establish a measured reduction in monthly close time.

Bring a normal batch, a returned payment, and a month-end timing difference to a Wingspan demo. Ask finance to reconstruct the payable, cash movement, fees, and GL handoff from the records provided. Accept the workflow only when your team can explain the remaining differences.