Payment journals deep dive in Business Central

The payment journal is the workhorse of AP cash outflow in Business Central. It batches vendor payments into a single review-and-post cycle, applies them against open invoices, generates payment files for the bank, and writes the bank ledger entries that flow into reconciliation. Most BC finance teams run it once or twice a week.

Where it lives. Navigation: Finance → Payment Journals or via search. The page shows lines like a journal — each line is one payment (one vendor, one amount, one bank account, one application). The template PAYMENT and a batch (often WEEKLY or DAILY) determine the posting setup.

Suggesting payments. The Suggest Vendor Payments action pre-fills the journal with proposed payments. Parameters:

• Last Payment Date — only invoices due on or before this date.
• Find Payment Discounts — include payment-discount lines for invoices within the discount window.
• Available Amount (LCY) — cap by cash available.
• Posting Date — the payment date.
• Starting Document No. — the number series start for posted payments.
• Bank Payment Type — Manual, Computer Check, Electronic Payment, etc.
• Bal. Account No. — the bank account to draw from.
• Summarise per Vendor — one line per vendor totalling invoices, vs. one line per invoice.

The action populates the journal with a draft batch the finance team then reviews and adjusts.

Application. Each payment line carries Applies-to Doc. Type and Applies-to Doc. No. — pointing to the invoice being paid. Summarised lines use Applies-to ID, with multiple invoices flagged. Without an application, the payment posts as an unapplied vendor payment that has to be reconciled later.

Payment methods. The vendor card's Payment Method Code drives default behaviour:

• CHECK — a printed check; posts via Check Printing.
• BANK — an electronic bank transfer (ACH, BACS, SEPA, depending on locale).
• CASH — manual.

Payment methods also drive which bank account format applies and whether the export goes through SEPA, NACHA, EFT files.

Bank Payment Type. A second axis on the line:

• Manual Check — physical check, no printing through BC.
• Computer Check — BC prints the check.
• Electronic Payment — generates an electronic export file.
• Electronic Payment-IAT — international ACH.

Generating bank files. With Bank Payment Type = Electronic Payment, the Export action on the payment journal calls a Data Exchange Definition specific to the bank account's payment export format and produces the file. SEPA Credit Transfer (Europe), NACHA (US), BACS (UK) are the common ones; per-country localisations add others. The file is uploaded to the bank portal or exchanged via a bank connector.

Voiding before posting. Until the journal posts, lines are mutable. If a vendor calls to dispute an invoice mid-cycle, the line can be deleted. After posting, the cycle is to void/reverse the payment (creates a counter entry).

After posting.

• Bank Account Ledger Entry is written reducing cash.
• Vendor Ledger Entry is written (negative — paying down balance).
• Detailed Vendor Ledger Entry records the application.
• G/L Entry captures the journal effect: debit AP, credit Bank.
• Posted Payment Reconciliation Lines seed the bank reconciliation.

Payment discounts. When an invoice carries a payment discount and the payment lands within the discount window, the payment journal calculates the discount as a separate line (vendor discount G/L account). Vendors get a small Pmt. Disc. Tolerance Date field for grace. Done well, payment discounts often outweigh interest cost on the cash; mature AP automates the analysis.

Common pitfalls.

• Unapplied payments. Forgetting to apply leaves a credit on the vendor account; reconciliation gets messy.
• Wrong posting date. A payment dated in a closed period either fails or posts into the next; closing schedule must lead AP.
• Bank file rejected. Bank returns the file; need to void posted payments, fix bank info, re-run. Test bank exports with a real (small) payment before launching electronic payments.
• Currency mismatch. Payment in EUR against an invoice in USD with no FX setup → posting fails. Always set up cross-currency posting groups.
• Tolerances misconfigured. Payment discount tolerances allow partial discounts on slightly late payments. Set them once, document them.

Operational rhythm. A high-volume AP shop runs the payment journal twice weekly. Mature teams run a "dry run" earlier to identify problems (missing approvals, blocked vendors, currency issues) and fix them before the production run.