Automating bank payment files without losing separation of duties

What separation of duties means here

No single person, and no single account, should be able to both create a payment and release it. In a payment run that gives four duties to keep apart:

1. Maintaining vendors and their bank details.
2. Selecting which invoices to pay.
3. Approving the payment batch.
4. Releasing the file to the bank.

Automation adds a fifth actor: the pipeline. The pipeline prepares. People approve and release. The pipeline’s service account must not hold any right that lets it do a person’s part.

What the pipeline does

The pipeline starts after Finance has selected a payment batch in the ERP. It does not choose what gets paid. It does the mechanical work:

• Reads the batch from the ERP through a supported interface: the standard payment APIs, plus a custom API page for vendor bank details, which the standard APIs do not expose.
• Validates each line: a vendor bank account is present, the amount is positive, the payment date is valid, and the same payment has not been sent before.
• Builds the file in the bank’s format. For ACH in the United States that is normally the NACHA layout, with the bank’s own rules on top. For checks, it is usually a check issue or positive pay file.
• Computes control totals: the number of payments, the total amount, and a hash of the finished file.
• Stores the file in a location that only the pipeline can write to and only the approver can read.

Business Central has its own payment export and approval workflow features. In the US that means the payment journal’s electronic payment export and the positive pay export, plus approval workflows on journal batches. Use them where they fit. A pipeline is for the cases where they do not, such as more than one ERP or a bank layout the standard export does not produce.

Where the approval gate goes

The gate goes between the finished file and the bank. Not before the file is built. An approval given before the file exists is an approval of something the approver has not seen.

At the gate the pipeline stops and sends the approver a summary: the batch, the number of payments, the total amount, and the list of payees and amounts. The approver compares the totals with the payment run in the ERP. If they do not match, the approver rejects, and the batch goes back to the person who prepared it.

Four rules make the gate hold:

• The approver is not the person who selected the payments. The pipeline checks this and refuses a self-approval.
• The approver signs in with a personal account. No shared mailbox, no shared login.
• The file cannot change after approval. Before any transmission, the pipeline computes the hash again and compares it with the hash that was approved. If they differ, it stops.
• There is no bypass. If the approver is away, a named backup approves. The pipeline has no setting that skips the gate.

Release is the last step, and it belongs to Finance. Either a Finance user uploads the approved file in the bank’s portal, or the pipeline transmits it and the bank still requires a Finance user to release it. Either way the pipeline cannot move money by itself.

What is logged

For each batch, record enough to rebuild the run later:

• The batch identifier and the ERP company it came from.
• Who selected the payments and when.
• The payment count, the total amount, and the file hash.
• Each validation that failed and what was done about it.
• Who approved or rejected, and when.
• When the file was sent, to where, and the bank’s acknowledgment.

Keep the log where the pipeline can add entries and cannot edit or delete them. Keep it as long as your finance records policy requires.

What Finance keeps

Automation changes who types, not who decides. Finance keeps:

• The vendor master, including every change to vendor bank details. That change needs its own check, separate from the payment run.
• The choice of what to pay and when.
• The approval of each batch.
• The release at the bank, and the bank entitlements.
• The bank reconciliation after the payments clear.
• The list of who may approve, reviewed on a schedule.

Whoever maintains the pipeline keeps the code, the service account, and the runbook, and holds no approval right and no bank entitlement.

Stillmark builds payment file pipelines as ERP integration and automation projects, with the approval gate, the log, and a runbook included, and review and release kept with Finance.