---
title: "Bank (NACHA) File Payment Processing Policy"
sidebarTitle: "NACHA file payments"
description: "PBI's procedures and controls for processing client vendor payments through the Bank (NACHA) file process — including how vendor banking information must be collected and validated."
icon: "shield-halved"
---

> **For AI agents:** the complete documentation index is at [llms.txt](/llms.txt). Append `.md` to any page URL for its markdown version.

| Field | Value |
|---|---|
| **Owner** | Jonah Dellasega, Accounts Payable Senior Manager |
| **Department** | Accounts Payable |
| **Effective date** | May 1, 2025 |
| **Scope** | Processing client payments to vendors using the Bank (NACHA) file process within Intacct and clients' banking institutions. Covers secure handling, validation, and documentation of sensitive banking information, plus onboarding a new client's bank file format. |
| **Source** | `Accounts Payable Department/3. Payment Processing/NACHA (Bank File) Payment Processing Policy.docx` |
| **Audit** | Quarterly Accounts Payable audit program |

<Info>
  This is a **policy**, not a how-to guide. The controls below are audited quarterly. Deviating from them is a compliance issue, not a matter of preference.
</Info>

## Definitions

| Term | Meaning |
|---|---|
| **ACH** (Automated Clearing House) | A network used for electronically moving money between bank accounts. |
| **Bank (NACHA) file** | A standardized file format used to initiate ACH payments. |
| **Banking information** | Bank name, routing number, account number, account type, and account holder name. |

## Responsibilities

| Role | Responsibility |
|---|---|
| **Accounts Payable Senior Manager** | Defines the policy, ensures adherence, and modifies the policy when needed. |
| **Accounts Payable Processor** | Prepares and validates NACHA files. |
| **Client Manager** | Verifies accuracy and completeness of payment information before submission to the bank. |

## Onboarding a client's bank file format

Complete this research before implementing ACH payments by bank file for a new client. Skipping it produces a file the bank silently rejects.

<Steps>
  <Step title="[Client Manager] Contact the client's bank">
    When onboarding a new client or planning to implement ACH payments via bank file, contact the client's bank relationship manager or treasury support team to ask about ACH capabilities and the required file format — for example Standard NACHA, CTX, CCD, or a bank-specific format.
  </Step>

  <Step title="[Client Manager] Request the bank's specifications">
    Request a sample ACH file layout, technical specification document, or implementation guide from the bank. This contains the required structure, field mappings, and delimiter or spacing rules.
  </Step>

  <Step title="[Client Manager] Review with the PBI Intacct admin">
    Provide the bank's specification to PBI's Intacct Administrator to determine what format customization is required within Intacct.
  </Step>

  <Step title="Customize the Intacct export template">
    If the client's bank requires a non-standard NACHA format, work with the Intacct Admin or Sage Intacct support to create or modify a custom bank file template under **Cash Management → Payment Formats**.
  </Step>

  <Step title="Validate a test file">
    Upload a sample bank file to the client's bank portal — in a non-processing or test environment if one is available — to validate that the file is accepted. Troubleshoot errors with the bank and Intacct support as needed.
  </Step>

  <Step title="Document the format requirements">
    Once finalized, upload a copy of the bank's ACH specification and a sample accepted file to the client's SharePoint folder under **ACH File Specs**, for future reference and audits.
  </Step>
</Steps>

## Collecting vendor banking information

Vendor banking details are ideally submitted through the online Microsoft Form managed by PBI: [bit.ly/achenroll](http://bit.ly/achenroll).

In other cases, details may arrive by email, paper documentation, or — rarely — a phone call.

<Warning>
  PBI and clients should actively steer vendors to the Microsoft Form. It provides better security and creates an audit trail of submissions. **Email and physical documents containing banking information are heavily discouraged.**
</Warning>

## Validating banking information

All newly submitted or updated banking information must be validated **before** vendor master data is updated.

<Steps>
  <Step title="[Client Manager] Call the vendor to confirm">
    Call the vendor and confirm the banking information verbally.

    <Note>
      Whenever possible, confirmation should come from **a different person than the one who submitted the information**. This is the control that defends against a compromised vendor email account.
    </Note>
  </Step>

  <Step title="[Client Manager] Update the vendor master data">
    Once confirmed, update the payment type and banking information in the vendor master data within Intacct. Set the **Vendor Type** in Intacct to **Bank File**.
  </Step>

  <Step title="[Client Manager] Document the validation">
    Record the following in the vendor master data in Intacct:

    - The validation date
    - The vendor contact who confirmed
    - The responsible PBI employee

    **Expected outcome:** the vendor record shows Bank File type, current banking details, and a dated validation note naming both parties.
  </Step>
</Steps>

<Warning>
  **If a vendor cannot confirm their banking information**, treat the submission as potentially fraudulent. The client manager must immediately inform both the vendor and PBI's client of a possible attempt.
</Warning>

## Preparing and reviewing the NACHA file

<Steps>
  <Step title="[AP Processor] Select the invoices and notify">
    Select the invoices to be paid by NACHA (Bank File) in Intacct, then notify the client manager that the payments have been selected.
  </Step>

  <Step title="[Client Manager] Generate and save the bank file">
    Log in to Intacct and generate the bank file in the format required by the client's bank.

    Save the file in the **Accounting Managers SharePoint** under the **ACH Payment File** folder, in the client's subfolder.
  </Step>

  <Step title="[Client Manager] Load the file at the bank">
    Log in to the client's bank, navigate to the payment section, and initiate a payment by loading the bank file downloaded from Intacct.
  </Step>

  <Step title="[Client Manager] Reconcile before releasing">
    Confirm the payment vendors and amounts line up with what is listed in Intacct. Only once everything reconciles can the payment be processed.

    <Warning>
      This review is the last point at which an incorrect or fraudulent payment can be stopped. Do not treat it as a formality.
    </Warning>
  </Step>

  <Step title="[Client Manager] Authenticate and submit">
    The bank asks for password validation plus a token code, received either from a hard token issued by the bank or a soft token on the client manager's cell phone.

    **Expected outcome:** the bank accepts the file and the payments are released for settlement.
  </Step>
</Steps>

## Policy audit

This policy is audited through the **quarterly Accounts Payable audit program**, which tests the controls above for collection, verification, and documentation of vendors' sensitive banking information.

## Related documents

- [Enable ACH payments for a vendor](/internal/sops/accounting/ap/ach-vendor-setup) — the Intacct steps once validation is complete
- [Vendor EFT onboarding letters](/internal/sops/accounting/ap/vendor-eft-onboarding-letters) — the client letter directing vendors to the enrollment form
- [Positive pay file policy](/internal/sops/accounting/ap/positive-pay-file-policy) — the equivalent control for paper checks
- [Add a new vendor in Sage Intacct](/internal/sops/accounting/ap/adding-a-vendor)