Payroll, Supplier and Tax Payment Execution. Prepare and release payroll, supplier and tax instructions with verified deadlines, funding, entry-level recovery and financial reconciliation.
At a fictional US manufacturer, Thursday's payment desk has three priorities: Friday wages for 240 employees, an approved supplier invoice for $84,000 and a federal employment-tax deposit. The ERP labels all three ready. The bank still needs to establish authority, destination, funding, timing and the right execution service. A single uploaded file or successful portal login cannot settle all three obligations.
Chapter 48 distinguished collection authority from the underlying loan, payroll deduction and government receivable. This chapter moves to the payer's execution process. It starts with approved obligations and follows their preparation, bank acceptance, release, settlement evidence and reconciliation. Payroll calculation, invoice approval and tax computation remain upstream responsibilities rather than being retaught here.
A payment run is a controlled population of instructions. Its success must be established at the level of each obligation, not inferred from a file acknowledgment or one debit to the employer's account.
Allow roughly 60 minutes for the chapter, diagrams and worked cases. Businesses, payment runs and internal deadlines are fictional. Published service times are identified explicitly. Tax schedules and legal requirements must be applied to the actual taxpayer and period; the chapter is an execution lesson rather than a tax-calculation guide. Sources were checked on October 5, 2026.
Chapter navigator
- Define what the payment desk is executing
- Participants and outsourced responsibilities
- Prepare payroll without exposing or duplicating wages
- Prepare supplier instructions and usable remittance
- Prepare federal tax payments correctly
- Files, APIs and rail-specific data
- Validate, authorize, fund and release
- Build a calendar that separates service deadlines
- Execute taxes through the correct service
- Where money moves and what settlement proves
- Returns, reversals and payment-run recovery
- Fraud, sanctions and sensitive payment changes
- Reconciliation, accounting and completion reporting
- Implementing the execution service inside a bank
- Worked cases and implementation decisions
- Role checklist and learning closure
1. Define what the payment desk is executing
Payroll execution delivers approved net wages to employees and separately handles other approved payroll-related obligations. Supplier execution pays an approved commercial liability with references that allow the supplier to apply the receipt. Tax execution delivers the correct amount to the correct authority, taxpayer account, tax type and period through an accepted service.
Those purposes affect the required data and evidence. An employee's net wage must not be confused with the employer's aggregate funding transfer to a payroll provider. A supplier's invoice number is not a substitute for a validated bank destination. A tax payment's bank amount is insufficient without the tax identity and period needed for correct application.
The payment desk should receive a frozen, approved version of each instruction or batch. If payroll recalculates a wage, AP changes an invoice allocation or tax adjusts the amount, identify the new version and its approval. A spreadsheet edited after authorization should not silently become the bank's release source.
Use a stable business reference for the obligation and separate bank instruction references. A payment can require another attempt after a definitive failure without creating another wage or invoice. Conversely, a new payroll period is a new obligation even if the employee and amount match the previous period.
The manufacturer's three priorities therefore enter one operational queue with different requirements. The common framework provides control and visibility; it does not erase the differences in payment purpose, recipient, calendar or evidence of completion.
2. Participants and outsourced responsibilities
The employer or business owns the underlying payment obligation. Its payroll, AP or tax team supplies approved instructions. Treasury provides funding and execution priorities. The originating bank validates and processes instructions within its service. Receiving institutions post the relevant credits. Payment operators and settlement arrangements perform their respective rail functions.
A payroll service provider may calculate, prepare, originate or fund payments under its agreement. The bank should distinguish those functions. An employer's transfer to the provider establishes funding of that relationship, not necessarily delivery of wages or tax deposits. The provider's reports and downstream financial evidence must complete the story.
The IRS states that outsourcing does not generally remove an employer's employment-tax responsibilities, while particular arrangements can change the allocation of liability. Its guidance distinguishes payroll service providers, reporting agents, section 3504 agents and certified professional employer organizations. Do not make the universal claim that every employer remains solely liable in every arrangement, or that every outsourcing contract transfers liability away.
For implementation, record which party is authorized to submit, change and cancel instructions and which party must provide evidence after execution. The bank needs a clear contact for a rejected payroll batch, an uncertain supplier payment and a tax-format problem. A generic vendor-support address is not enough for a time-critical exception.
The receiving employee or supplier should not have to understand those contracts to report non-receipt. The payer's support process should collect the relevant details and follow the responsibility map internally.
3. Prepare payroll without exposing or duplicating wages
The approved payroll population should identify each employee payment, destination, amount and pay date, together with the payroll run and version. Separate the employee's business identifier from bank-account details. Restrict access to salary information and avoid placing full payroll files in general incident tickets or shared mailboxes.
Validate completeness before bank submission. Compare the expected employee population and totals to the file produced for payment. An aggregate amount can be correct even if two employees' payments were swapped or one was duplicated while another was omitted. Counts, individual identities and amounts all matter.
Account changes should come through the controlled employee-maintenance process. A message asking payroll to send wages to a new account immediately before release is a fraud risk, even if it appears to come from the employee. Verify the change through an established independent process and preserve its effective period.
Payroll may be delivered by ACH credits or another supported method, but the choice must meet the applicable employment and payment requirements. Regulation E's compulsory-use rule restricts requiring an employee to establish an account at a particular institution. State wage-payment rules also need consideration. A bank's preferred product should not be presented as the only legally permissible way to receive wages.
The employer should reconcile employee net-pay instructions separately from deductions and taxes. The employee batch may be fully successful while a tax instruction remains unsent. A dashboard called payroll complete needs a defined scope so users do not mistake wage delivery for completion of every associated obligation.
4. Prepare supplier instructions and usable remittance
AP supplies the approved payable and allocation: supplier, invoice references, amount, currency and any agreed deductions or credits. The payment instruction needs a verified destination and the intended execution date. The remittance needs enough detail for the supplier to understand what the payment covers.
For the $84,000 invoice, the manufacturer might pay the full amount or an approved net amount after a credit. The bank should process the authorized amount and preserve the references; it should not decide whether the underlying commercial deduction is justified. The supplier's application process needs the agreed explanation separately from the bank's financial confirmation.
Protect payee maintenance from invoice presentation. A changed account printed on an invoice should not automatically overwrite the supplier master. The FBI's business-email-compromise guidance identifies apparently legitimate payment-change requests as a key fraud pattern. Independent verification and controlled approval should happen before release, with evidence of the destination actually authorized.
If one payment covers several invoices, retain the allocation total and the individual references. If one invoice is paid in installments, retain each payment's relationship to the original liability. Those relationships prevent a duplicate invoice from entering the next payment run merely because the first payment was partial.
The bank can send a payment successfully while remittance delivery fails. Operations should be able to resend the remittance without sending money again. Treat advice delivery and financial execution as linked but separate objects.
5. Prepare federal tax payments correctly
A federal tax payment requires the correct taxpayer identity, tax type, period, amount and payment date using the selected service's requirements. Tax calculation and deposit-schedule determination belong with the taxpayer's responsible tax process. The payment desk should validate required data and execute the approved instruction rather than infer a tax period from the date of upload.
Distinguish a tax return from a tax payment. Filing a return does not itself prove that a required deposit was made. A payment can also be applied to an incorrect tax period even when the bank debit is genuine. Execution evidence must therefore connect to tax-account application, not stop at a transaction amount.
IRS guidance describes monthly and semiweekly employment-tax deposit schedules and other conditions, including special rules. The appropriate schedule depends on the taxpayer's circumstances; it is not simply the employer's chosen payroll frequency. A company paying wages twice a month should not infer that its federal deposit deadline follows the same cadence.
The IRS's current EFTPS page states that individuals can no longer create new EFTPS accounts and that existing individual users can still use it for now. This chapter's employer example concerns business tax execution. It does not teach new individual enrollment or claim a final individual shutdown date that the current source does not confirm.
State and local taxes require their own portals, formats and timing. An IRS payment reference cannot be reused as evidence of a state deposit. The bank's service catalogue should identify which authorities and payment types it supports and the current specifications for each.
6. Files, APIs and rail-specific data
The customer-to-bank interface may be a portal, file or API. It can carry a batch of instructions or individual payments. The interface acknowledgment confirms only the event defined by its contract: receipt, syntactic acceptance or another specific stage. It does not automatically establish bank release or settlement.
Nacha's developer guide describes fixed-width ACH records and distinguishes SEC codes such as PPD, CCD and CTX. Consumer payroll credits commonly use PPD; business payments can use appropriate corporate formats such as CCD or CTX, depending on the transaction and remittance need. The bank must apply the current rules and its agreed file specification rather than select a code solely because the file is called payroll or suppliers.
A bank may accept ISO 20022 customer instructions such as pain.001 where its service supports them and translate into the selected rail. That does not make ACH an ISO 20022 clearing service. Production schema versions, profiles, mandatory fields and status messages must come from the bank's current implementation guide. The chapter does not invent a universal US corporate-bank API.
Keep file, batch and entry identifiers distinct. A file can contain multiple batches, and individual entries can have different outcomes. If the bank rejects only one instruction under its service model, the customer needs to identify that instruction without resubmitting the successful population.
For tax execution, use the selected tax service's required data and supported route. An arbitrary free-text reference on an ordinary supplier payment is not a reliable substitute for a properly formatted tax instruction.
7. Validate, authorize, fund and release
The bank should establish the submitting customer's identity and authority, validate instruction data, apply relevant risk controls and determine whether the payment can be funded and executed as requested. The precise internal sequence is bank-specific. The important requirement is that the evidence and decisions remain connected to the exact released instruction.
An illustrative maker-checker workflow allows one user to prepare a run and another entitled user to approve it. The bank should bind approval to the relevant contents and version. A payment amount or destination changed afterward requires the appropriate new approval rather than inheriting authority from an earlier file.
The diagram separates correction before release from investigation after release. A rejected instruction can return to preparation; an instruction already sent to a rail needs its actual outcome established before replacement. That boundary is particularly important when a payroll deadline creates pressure to send another batch.
Treasury should verify both customer funding and bank settlement capacity relevant to the method. Money available in the customer's account does not automatically mean every settlement account or correspondent arrangement is ready. Conversely, a bank's liquidity does not authorize it to pay an unfunded customer instruction outside the agreed credit arrangement.
Record the release timestamp and evidence. A payment queued awaiting approval should not appear in the same completed total as one accepted by the downstream payment service. Clear state definitions support both customer commitments and operational prioritization.
8. Build a calendar that separates service deadlines
A payment run has a business due date, a customer submission deadline, a bank release deadline and a rail processing schedule. The bank may set an earlier customer cutoff to allow validation and correction. The customer should not use an operator's final deadline as though it were the bank's promised acceptance time.
The published FedACH schedule lists Same Day ACH input deadlines of 10:30 a.m., 2:45 p.m. and 4:45 p.m. Eastern Time, with corresponding settlement at 1:00 p.m., 5:00 p.m. and 6:00 p.m. Eastern Time. These are FedACH processing points for eligible activity, not universal corporate submission cutoffs or a promise that every instruction uploaded at those times will qualify.
The current Same Day ACH per-entry limit remains $1 million; Nacha's published increase to $10 million is effective September 17, 2027. Eligibility must be evaluated per entry, not by treating a batch total above $1 million as automatically ineligible. The detailed ACH chapters cover the complete service conditions.
For the manufacturer, plan wages early enough to resolve problems before the agreed payday. Do not assume an employee's bank will provide discretionary early availability. Supplier payments should use the contractual due date and receiving capability. Tax instructions need their own service deadline and deposit requirements.
Calendar logic should use the relevant time zone and banking holidays, with explicit treatment of requested dates that are not supported. A silent date shift can create a late wage or tax payment even though the file remains technically valid. The customer should see the executable date before release where the service allows that decision.
9. Execute taxes through the correct service
EFTPS distinguishes scheduling from the later financial movement. Its published website and voice-response deadline is 8 p.m. Eastern Time at least one calendar day before the tax due date for timely receipt under that service. That time is not the final FedACH Same Day window, and the two must not be interchanged.
The IRS also describes same-day wire tax payments through a financial institution. The payer supplies the Same-day Taxpayer Worksheet, and separate tax forms or periods require separate worksheets. The IRS directs users to their financial institution for availability, fees and cutoffs and provides a Financial Institution Handbook for formatting and processing. A bank should follow that current specification rather than send an ordinary wire with a vague tax reference.
The diagram shows alternate execution paths, not two payments that should both be made. Before using a replacement route, establish whether an existing instruction remains scheduled or has already executed. Paying by wire while an original debit remains active can create a duplicate tax payment even if both methods are individually valid.
A tax confirmation, bank statement and tax-account record answer different questions. Preserve the scheduling reference, actual bank outcome and correct taxpayer-period application. If an amount appears against the wrong period, use the authority's supported correction process rather than cancel an unrelated bank transaction.
The payment desk should have an escalation procedure for a missed cutoff that identifies the tax team and the bank's specialist service. It should not promise that selecting a faster ordinary rail automatically cures a tax deadline or formatting problem.
10. Where money moves and what settlement proves
For payroll ACH credits, the originating arrangement sends entries through the ACH system, interbank settlement affects the participating institutions' settlement positions and the receiving banks post employee credits. The employer's debit, bank settlement and each employee's posting are connected events. An employer funding a payroll provider adds a separate relationship before the employee payments.
Supplier execution follows the actual selected rail. An ACH credit uses its clearing and settlement model. A Fedwire payment uses real-time gross settlement through Federal Reserve accounts under its rules. An on-us transfer can move between customer accounts on one bank's books without a separate interbank settlement for that transfer. Earlier chapters explain those rails; the execution desk must select and report the correct one.
Tax execution also requires the tax-service identity and application evidence. Settlement of funds does not by itself prove correct tax classification. The bank should connect the financial instruction to the service confirmation and leave tax-account application visible as a distinct control where evidence is available.
A supplier remittance email and an employee payslip do not settle money. They explain the business purpose. Likewise, an ISO 20022 status message is evidence of the status it actually reports, not a substitute for examining whether that status means receipt, acceptance, rejection or financial completion in the relevant implementation.
The bank's customer report should state its evidence boundary. If it confirms release and settlement but lacks direct recipient-account confirmation, it should not invent a beneficiary acknowledgment. Non-receipt investigation can obtain additional evidence through the supported route.
11. Returns, reversals and payment-run recovery
An ACH return, an allowed reversal, a pre-release cancellation and a request for recovery are different actions. Nacha's current reversal guidance describes reversals as a mechanism for certain genuine sender errors within the applicable rules and timeframes. A funding problem is not a general license to reverse correct payroll credits.
If the manufacturer duplicated a payroll batch, establish the actual duplicate entries and obtain the bank's supported correction treatment. Do not reverse every entry from both batches or assume every reversal will recover funds. Customer communication and accounting should distinguish the original wage obligation, erroneous duplicate and attempted recovery.
A returned employee credit leaves the wage-delivery obligation unresolved. Verify the destination through the controlled process, establish the returned funds and authorize the replacement. A supplier payment returned for a closed account similarly requires destination correction and a linked new attempt. Neither creates a new wage expense or new supplier invoice merely because another payment is needed.
The diagram prevents the common full-batch resend error. Successful entries remain successful; definitively failed entries can enter controlled correction; uncertain entries require inquiry. A bank should report the amount and population in each category before the business decides how to meet the remaining obligations.
Tax payment recovery must use the applicable tax-service process. A bank cannot guarantee reallocation between tax periods by changing a local reference field. Preserve the original tax evidence and involve the taxpayer's responsible team.
12. Fraud, sanctions and sensitive payment changes
The most consequential changes often occur before the payment file exists. A fraudulent supplier account change or payroll redirection can produce a perfectly valid bank instruction. Controls should therefore connect master-data verification to the payment actually released, without treating successful file validation as evidence that the destination is legitimate.
Apply risk controls appropriate to amount, payee, recent changes, customer behavior and service. Urgent payroll or tax language can create pressure to bypass checks. The bank should have an escalation path that preserves necessary control and documents the decision rather than making urgency an automatic approval.
Sanctions controls and AML monitoring should reflect the bank's actual obligations and risk assessment. Tax and payroll purposes do not make every transaction inherently exempt. Equally, the chapter does not prescribe a mandatory identical screening sequence for every bank. Production requirements need the approved policy, available data and applicable legal basis.
Protect tax identifiers, employee details and credentials in files, logs and reports. Give operations enough information to investigate without exposing full payroll data to every user. Access and audit evidence should cover both routine submissions and emergency manual instructions.
For a discovered payment diversion, contact the relevant bank or provider promptly through established channels and pursue supported recovery. Do not promise recovery before funds are located and the required actions succeed. The business also needs to correct compromised instructions still awaiting release.
13. Reconciliation, accounting and completion reporting
Reconcile the approved population to submitted instructions, bank acceptance, released entries, financial outcomes and business-ledger application. For payroll, preserve the employee and pay-period relationships. For suppliers, preserve invoice allocation. For taxes, preserve taxpayer, tax type and period. A single aggregate debit cannot close all these controls.
In an illustrative employer ledger, successful wage payment reduces wages payable and cash according to the posting policy. A returned wage payment restores the relevant payable or clearing position; a replacement should clear that obligation rather than book another wage expense. Supplier and tax payments similarly settle their respective liabilities, with any intermediate clearing accounts reconciled.
The bank's own ledger is a different perspective. Customer-account postings, settlement-account movements and bank control accounts need their own reconciliation. The customer reducing AP does not debit the bank's settlement account directly. Clear perspective prevents journal examples from combining two entities' books into an impossible entry.
A completion report should show accepted, rejected, released, settled or otherwise confirmed, returned and unresolved populations using the service's actual evidence. Include both counts and values and identify the next action for open items. A file can be fully received and only partly executed.
Tax evidence should be retained independently of a payroll provider's summary. Where the employer's arrangement leaves responsibility with it, verification of deposits is an important practical control. The service should make it possible to retrieve confirmation for the correct taxpayer and period without relying only on a provider's claim that all taxes were handled.
14. Implementing the execution service inside a bank
Build the service around business obligations, approved versions, execution attempts and financial events. Reuse file transport, authentication and monitoring components, but retain purpose-specific validation and reporting. Payroll confidentiality, supplier remittance and tax formatting are not optional variants of a generic amount-and-account record.
The bank's implementation guide should define customer cutoffs, permitted dates, supported formats, batch behavior and inquiry procedures. Make partial acceptance behavior explicit. A customer must know whether to correct one entry or replace an entire rejected file, and how the bank prevents duplicate execution.
Test a clean run and at least one realistic interruption at each boundary: changed data after approval, failed funding, invalid entry, lost acknowledgment, partial execution, later return and remittance-delivery failure. The expected result should identify the financial population and the authorized next action, not merely an error code.
Operations readiness includes an escalation owner for time-critical wages and taxes, a safe manual process and an end-of-day unresolved inventory. Manual instructions should carry the same obligation references and duplicate controls as the automated channel. Otherwise the contingency procedure can create the duplicate the primary system prevented.
The release criterion is whether the bank and customer can explain each remaining obligation after a disruption. A system that processes a perfect file quickly but cannot recover a partially completed payroll run is not ready for real execution.
15. Worked cases and implementation decisions
A payroll file is accepted but one entry fails
The manufacturer submits 240 employee credits totaling a fictional $480,000. One $2,000 instruction fails definitively before release, leaving 239 instructions totaling $478,000 in the successful execution population. Correct and approve the failed instruction without resending the 239. Reconcile the original total to the successful and failed populations before creating the replacement attempt.
Now suppose the bank's report for another $2,000 entry is missing. That item is uncertain, not automatically rejected. The learner should create separate categories and use inquiry before replacement. Equal amounts do not make the two cases interchangeable.
A supplier changes accounts immediately before release
The $84,000 supplier invoice arrives with new bank details. The payment desk should verify the change independently through the established supplier relationship and controlled maintenance process. The invoice attachment alone is insufficient. If the change is genuine, approval should bind the new destination to the payment version actually released.
If the original instruction was already sent, updating the supplier master does not redirect it. Establish its outcome before a replacement. Explain to AP why the invoice can remain due commercially while the bank must still investigate an existing transfer to avoid paying twice.
A tax deadline is confused with a rail deadline
A user assumes the final FedACH Same Day window is the cutoff for an EFTPS website instruction. It is not. The EFTPS scheduling deadline and the bank's supported same-day tax-wire process are separate. Review the existing instruction's status, involve the tax team and use the correct service with its required data and bank cutoff.
The learner should identify the exact evidence needed before switching routes: whether the original remains active, whether the alternate tax service is available and whether the taxpayer-period information is valid. A faster payment with incorrect tax data is not a complete solution.
A provider received funding but wages are missing
The employer's bank confirms its funding transfer to a payroll provider. Employees report no wages. Investigate the provider's downstream payroll instructions and outcomes. The employer-to-provider transfer does not prove employee delivery. Preserve both legs and establish the unresolved wage population.
If emergency replacements are needed, first coordinate with the provider so queued originals do not later pay the same employees again. The recovery plan should identify who controls those originals and how their final state will be evidenced, not rely on a verbal statement that the provider is offline.
A duplicate payroll run is discovered
Two identical runs were released under different file names. Determine which entries actually processed and assess the bank's supported reversal or recovery process under current rules. Do not use an ordinary debit to retrieve wages without the required basis. Do not assume every recipient still has the duplicate amount available.
The employer's books should distinguish valid wage expense from the erroneous duplicate and any recoverable amount. The bank's investigation should retain both run identifiers and entry references. Renaming one file or deleting it from the portal does not resolve the financial duplication.
Tax money is applied to the wrong period
The bank evidence confirms a federal tax payment, but the taxpayer record shows it against another period. The tax team should use the IRS's supported correction process with the original payment evidence. The payment desk should not send a second payment solely to make its own period report match without an approved decision.
For learning closure, identify the three records: approved tax obligation, financial execution and tax-account application. Explain which one is wrong and which remains true. That separation is the difference between a precise correction and another payment that increases the reconciliation problem.
16. Role checklist and learning closure
Product should define the execution promise for each purpose. Business analysis should preserve obligation, version and attempt identity. Technology should validate purpose-specific data and prevent duplicate release. Operations should isolate failed and uncertain entries. Treasury should fund the correct accounts and respect the relevant calendars. Finance should reconcile liabilities and bank evidence at the appropriate entity level.
The manufacturer's payment desk can now answer three distinct questions: did employees receive the intended wages, did the supplier receive and understand its payment, and was the tax payment executed and applied correctly? One file acknowledgment cannot answer all three.
Chapter 50 broadens the view to corporate AP, consumer payouts and disbursement models, including recipient choice, unclaimed payments and safe delivery across several methods.
Authoritative references
Sources checked on October 5, 2026. Operator times are not customer-bank cutoffs. Tax deadlines depend on the actual taxpayer and obligation. The $10 million Same Day ACH limit is a future change effective September 17, 2027.
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.