Only part of a bank payment batch was accepted

Download the bank's acknowledgment and detailed status report for the original file. Record the file identifier, submission time, payment count and total value. Then identify the state of each instruction. An aggregate status is not enough to determine which suppliers have been paid.

HSBC's payment documentation distinguishes initial validation acknowledgments from later payment status and includes partial processing. This is a useful example of why the business must understand its own bank's status definitions. Accepted, processing and completed can describe different stages; ask the bank which evidence confirms settlement for the payment method in use.

Keep every original instruction in a control schedule with its internal payment reference, supplier, amount, currency and latest bank status. Add the rejection reason or follow-up owner. Reconcile the schedule's count and value to the file submitted, including items still awaiting a clear result.

Group the outcomes by what they require next. A rejected beneficiary detail needs correction; an instruction awaiting approval needs an authorized approver; an uncertain status needs investigation. Treating every item outside the completed group as failed can create duplicate payments when processing catches up.

Preserve changes over time rather than overwriting the only status record. A transaction that first appeared accepted may later be returned, while an initially pending item may settle. Date each update and retain the bank report supporting it.

Create the replacement population from instructions the bank confirms were not executed. Keep the original reference and assign the new reference required by the bank's process. Document the correction and approval. Do not resend the entire file because its overall label includes the word partial.

Check whether the accounting system has already marked rejected invoices paid. Correct those records through the supported workflow so the next run does not pay both an existing instruction and a reopened invoice. When the system cannot represent the bank's detail, retain a controlled exception schedule and make the limitation explicit.

Before releasing the retry, compare its suppliers and amounts with the original settled population. Have another authorized person review the comparison where practical. The purpose is to establish exactly which obligations remain unpaid, rather than merely producing a new file that passes validation.

Match bank debits and any returns to individual instructions or supported batch totals. A bank may show one debit for several payments, so retain the detail that connects the amount to the supplier ledger. Keep fees separate from principal where the evidence allows.

Review remaining uncertain items before sending supplier remittance advice or updating the cash forecast. Report the expected outgoing amount and unresolved exposure separately. A second batch can change the funding requirement even when the first batch's overall total looked correct.

The completed control record should connect the original file, all status reports, approved retries and final bank movements. Investigate repeated rejection reasons with the bank or system owner. Fixing a recurring format or approval problem will reduce future exceptions more effectively than manually rebuilding every payment run.