This section provides, as an example, an overview of the normal processes involved in EDI payment processing, that is, how electronic payments processing is used. Not everything in this example applies to the use of X12 in all possible payments processing scenarios.
EDI payments processing encompasses both collection and disbursement transactions. The exchange of funds is accomplished by means of credit and debit transfers. Transfers can also include a related bank balances, as well as transactions and account-analysis reporting mechanisms.
Most nonmonetary EDI TP communications are handled either directly between the parties or indirectly through their respective value-added networks (VANs). However, the exchange of funds requires a financial intermediary. This “third party” is normally the bank or banks that hold deposit accounts of the two parties.
The EDI operations involve the exchange of remittance information along with the order to pay. The remittance information, which acts as an electronic check stub, can be sent in any of the following ways:
Directly between TPs or through their respective EDI VAN mailboxes
Through the banking system, with the beneficiary’s bank sending notice of payment to the beneficiary
By the originator to the originator’s bank as an order to pay, with the originator’s bank notifying the beneficiary
The TPs and the capabilities of their respective banks determine:
Routing of the electronic check stub
Whether payment is of the type:
Debit authorized by the payor and originated by the beneficiary
Credit transfer originated by the payor
The following types of information can be exchanged electronically between bank and customer:
Daily reports of balances and transactions
Reports of lock-box and electronic funds transfer (EFT) remittances received by the bank
Authorizations issued to the bank to honor debit transfers
Monthly customer account analysis statements
Account reconcilement statements
Statements of the demand-deposit account
The electronic payment mechanism, which is a subset of EDI, involves the following separate activities:
Exchange of payment orders, causing value to transfer from one account to another
Exchange of related remittance information in standardized machine-processable formats
An electronic payment can be either:
Credit transfer, initiated by the payor
Debit transfer, initiated by the payee as authorized by the payor
Regardless of how a credit transfer was initiated, the payor sends a payment order to its bank in the form of an X12 Payment Order/Remittance Advice (Transaction Set 820).
The bank then adds data in a format required by the United States by the National Automated Clearing House Association (NACHA) and originates the payment through the Automated Clearing House (ACH) system. A corporate-to-corporate payment then performs the following functions:
Transfers actual monetary value
Transfers notification of payment from payor to payee
When a credit transfer occurs, these two functions are sometimes treated as one, and sometimes treated separately. These functions can travel in either of the following ways:
Together through the banking system
Separately and by different routes
X12 Transaction Set 820 is a data format for transporting a payment order from the originator to its bank. This payment order can be:
Instructions to the originator’s bank to originate a credit transfer
Instructions to the TP to originate a debit transfer against the payor’s bank account
Once this decision has been made, Transaction Set 820 transports the remittance information to the beneficiary. The transfer can either be through the banking system or by a designated route separate from the transport of funds.
Whenever the Transaction Set 820 remittance information is not transferred with the funds, it can be transmitted directly from the originator to the beneficiary. It can also be transmitted through an intermediary, such as a VAN.
Before funds can be applied against an open accounts-receivable account, the beneficiary must reconcile the following data streams:
Payment advice from the receiving bank
Remittance information received through a separate channel
These data streams were separated during the transfer operation.
If this reconciliation does not take place, and if the amount of funds received differs from the amount indicated in the remittance advice, the beneficiary might have problems balancing the accounts-receivable ledger.
The value transfer begins when the originator issues a payment order to the originator’s bank. If a credit transfer is specified, the originator’s bank charges the originator’s bank account and pays the amount to the beneficiary’s bank for credit to the beneficiary’s account.
If the payment order specifies a debit transfer, the originator is the beneficiary. In this case, the beneficiary’s bank originates the value transfer, and the payor’s account is debited (charged) for a set amount, which is credited to the originator’s (beneficiary’s) bank account.
The payor must issue approval to its bank to honor the debit transfer, either before the beneficiary presents the debit transfer or at the same time. This debit authorization or approval can take one or more of the following forms:
Individual item approval
Blanket approval of all incoming debits with an upper dollar limit
Blanket approval for a particular TP to originate any debit
X12 uses an end-to-end method to route the 820 Payment Order/Remittance Advice from the originator company through the banks to the beneficiary. Use of this method means there can be several relay points between the sender and the receiver.
The Transaction Set 820 is wrapped in an ACH banking transaction for the actual funds transfer between the banks.