17.1 Processing Payment Journals & Cash Receipt Registrations

17.1 Processing Payment Journals & Cash Receipt Registrations

Quick Summary: In Microsoft Dynamics 365 Business Central, cash outflows and inflows are governed by dedicated journal templates and registration interfaces. Outbound vendor disbursements are processed via the Payment Journal (Page 256), leveraging the Suggest Vendor Payments batch routine to prioritize invoices by due date or payment discount date. The system supports computer checks (with distinct operational paths for unposted check voids versus posted financial voids) and electronic funds transfers (EFT/SEPA). Inbound customer collections are processed through the Cash Receipt Journal (Page 255), which automatically handles realized currency gains and losses upon application, or via the lightweight Register Customer Payments page (Page 268), which enables rapid posting of collections as individual entries or consolidated lump-sum bank deposits.

---

Payment Journal Execution & Vendor Disbursements

The Payment Journal (Alt+Q -> type Payment Journals, Page 256 / Table 81 Gen. Journal Line with Journal Template Type = Payments) is the central operational hub for issuing disbursements to vendors, employees, and other payees.

Payment Journal Processing Lifecycle:

[Suggest Vendor Payments Batch Job (Codeunit 415)]
                     │ Filters: Due Date, Available Funds, Pmt. Discounts
                     ▼
        [Populated Payment Journal Lines]
                     │
       ┌─────────────┴─────────────┐
       ▼                           ▼
[Bank Payment Type:         [Bank Payment Type:
 Computer Check]             Electronic Payment / EFT]
       │                           │
       ▼ Action: Print Check       ▼ Action: Export / Generate EFT
[Check Ledger Entry (272)]  [File Created: SEPA / NACHA]
 Status: Printed             Line Status: Exported
       │                           │
       └─────────────┬─────────────┘
                     ▼ Action: Post (F9) -> Codeunit 12
        [Posted Financial Transactions]
        - Table 25: Vendor Ledger Entry (Payment closed/applied)
        - Table 271: Bank Account Ledger Entry (Credit to cash)
        - Table 17: G/L Entries (Debit AP, Credit Cash)

The Suggest Vendor Payments Routine

Rather than keying payment lines manually, organizations execute the Suggest Vendor Payments batch job (Actions -> Prepare -> Suggest Vendor Payments, Codeunit 415). Key configuration parameters include:

• Last Payment Date: Identifies open vendor invoices with a Due Date on or before this cutoff date.
• Find Payment Discounts: Evaluates whether an early payment discount date falls within the payment horizon. If enabled, BC schedules payments early to capture vendor settlement discounts.
• Available Amount (LCY): Caps the cumulative suggested disbursement total to respect organizational liquidity or credit limits.
• Summarize per Vendor: Consolidates multiple invoices for the same vendor into a single journal line, reducing bank transaction charges and remittance volume.
• Bank Payment Type: Pre-populates lines with Computer Check, Manual Check, or Electronic Payment.

---

Computer Checks: Printing & Void Mechanics

When Bank Payment Type is set to Computer Check, Business Central coordinates the physical disbursement with Table 272 (Check Ledger Entry).

Printing Computer Checks

1. The user selects Check -> Print Check from the journal action bar.
2. The system opens the check report dialog (e.g., standard Report 1401 or localized report). The user verifies the Bank Account No., Next Check No., and formatting layout.
3. Upon printing, Business Central writes a record to Table 272 with Entry Status = Printed, records the assigned check number, and updates the payment journal line's Check Printed boolean field to Yes.
4. A journal line with Bank Payment Type = Computer Check cannot be posted until Check Printed equals Yes.

Check Void vs. Financial Void

A frequent source of confusion on the MB-800 exam is the critical architectural boundary between Void Check and Financial Void:

Check Cancellation Decision Framework:

Has the Payment Journal line been posted to the General Ledger?
                 │
        ┌────────┴────────┐
        ▼ NO              ▼ YES
[Action: Void Check]    [Action: Financial Void]
- Executed from:         - Executed from:
  Payment Journal          Bank Account -> Check Ledger Entries (Page 374)
- Table 272 Status:      - Table 272 Status:
  Voided                   Financially Voided
- G/L Postings: None     - G/L Postings: Offsetting reversal entries posted
- Line Status:           - Subledger Impact:
  Check Printed -> No      Reopens applied Vendor Invoices (Open = True)
  Permits reprint/edit     Restores Remaining Amounts

---

Electronic Payments: EFT and SEPA Workflows

For electronic disbursements (e.g., ACH in North America or SEPA Credit Transfers in Europe), the line's Bank Payment Type is designated as Electronic Payment.

Prerequisites for Electronic Transmissions

• Bank Account Card: Must define an active Bank Export Format mapped to a Data Exchange Definition (e.g., US-EFT or SEPADD).
• Vendor Bank Account: The vendor card must reference a Preferred Bank Account Code containing valid routing numbers, SWIFT/BIC, and IBAN/transit numbers.
• Payment Method Code: Must be configured with the appropriate export format mapping.

Export and Transmission Execution

1. In the Payment Journal, the user highlights the intended disbursement lines.
2. Selecting Bank -> Export executes the underlying Data Exchange Definition XMLPort or codeunit.
3. The system creates the electronic bank file (NACHA, ISO 20022 XML, or flat text) for upload to the bank portal.
4. Business Central updates the journal lines with Exported = True and sets Check Exported = True.
5. Posting Validation: If a line requires electronic export, Business Central's posting validation engine blocks posting (F9) if the file has not yet been exported, safeguarding against unrecorded electronic remittances.

---

Cash Receipt Journal & Multi-Currency Processing

Customer payments are processed via the Cash Receipt Journal (Alt+Q -> type Cash Receipt Journals, Page 255 / Table 81 Gen. Journal Line with Journal Template Type = Cash Receipts).

Foreign Currency Realized Gain/Loss Calculation:

[Invoice Date: May 1]
- Invoice Amount: 10,000 EUR @ 1 EUR = 1.10 USD
- Accounts Receivable Booked: $11,000 USD (Table 21 Cust. Ledger Entry)
                           │
                           ▼ Time Passes (Exchange rate shifts)
[Payment Receipt Date: June 15]
- Cash Received: 10,000 EUR @ 1 EUR = 1.15 USD
- Cash Value Received: $11,500 USD (Table 271 Bank Account Ledger Entry)
                           │
                           ▼ Applied & Posted in Cash Receipt Journal
[Automated G/L Postings via Codeunit 12]
- Debit: Cash / Bank Account ................. $11,500 USD
- Credit: Accounts Receivable ................ $11,000 USD
- Credit: Realized Exchange Gains ............   $500 USD (P&L Gain)
- Table 379 Detailed Cust. Ledg. Entry: Initial, Application, Realized Gain

Multi-Currency Cash Receipts

When customers remit payments in foreign currencies (FCY), Business Central dynamically handles currency fluctuations:

• Currency Code: If blank, the transaction operates in Local Currency (LCY). When specified, the system retrieves the exchange rate from the Currency Exchange Rates table corresponding to the Posting Date.
• Realized Gain/Loss Mechanics: If an invoice was posted on Date 1 at Rate 1, and the payment is received on Date 2 at Rate 2, the delta between the LCY equivalent of the invoice and the payment represents a Realized Exchange Gain or Realized Exchange Loss.
• When the cash receipt is applied and posted, Business Central automatically debits/credits the Realized Gains Account or Realized Losses Account configured on the Currency Card (Page 5 / Table 330) and fully balances the customer subledger.

---

Register Customer Payments: Streamlined AR Collections

For small to mid-sized businesses or decentralized collection desks, the standard Cash Receipt Journal can involve excessive accounting complexity. Business Central provides a dedicated, simplified interface: the Register Customer Payments page (Alt+Q -> type Register Customer Payments, Page 268).

Register Customer Payments Interface Architecture:

[Register Customer Payments (Page 268)]
  │ (Configured via Payment Registration Setup - Page 1051)
  │ Shows open customer invoices in an editable, spreadsheet-style grid
  │
  ├── User checks [Payment Made] on multiple invoices
  │
  ├── Posting Option 1: "Post Payments" (Process -> Post Payments)
  │     └── Result: Creates separate Bank Account Ledger Entries for each invoice
  │
  └── Posting Option 2: "Post as Lump Sum Payment" (Process -> Post as Lump Sum)
        └── Result: Creates ONE consolidated Bank Account Ledger Entry
                    Creates separate Customer Ledger Entries for each customer

Setup and Operational Behavior

• Payment Registration Setup (Page 1051): Defines the default Journal Template Name, Journal Batch Name, and target Bal. Account No. (operating bank account).
• Grid Mechanics: When opened, Page 268 dynamically queries Table 21 (Cust. Ledger Entry) for open invoices. The AR clerk simply verifies Date Received, adjusts Amount Received if partial, and checks the Payment Made box.

Individual Payments vs. Lump Sum Deposits

• Post Payments: Posts each selected line as an individual cash receipt. This produces discrete Bank Account Ledger Entries in Business Central. This is appropriate when receipts arrive as separate electronic credit card transactions.
• Post as Lump Sum Payment: Consolidates all marked receipts into a single Bank Account Ledger Entry, while generating individual, properly applied Customer Ledger Entries for each customer invoice. This matches physical bank deposit slips where 20 customer checks are deposited under one deposit total, dramatically streamlining month-end bank reconciliation.

---

Cash Management Processing Channels Comparison

---

Step-by-Step UI Execution Workflows

Workflow A: Generating and Posting Computer Checks via Suggest Vendor Payments

1. Press Alt+Q, type Payment Journals, and open the PAYMENTS batch (Page 256).
2. Select Prepare -> Suggest Vendor Payments (Codeunit 415).
3. In the request page, set Last Payment Date to the end of the current month, enable Find Payment Discounts, select Bank Payment Type = Computer Check, and click OK.
4. Review the generated lines. Highlight a line, click Check -> Print Check.
5. In the check printing dialog, confirm Bank Account No. and Next Check No.. Click Print.
6. Verify that the line now shows Check Printed = Yes and a check number is populated.
7. Press F9 (or select Post/Print -> Post) to commit the transactions to the ledger.

Workflow B: Processing Lump-Sum Bank Deposits via Register Customer Payments

1. Press Alt+Q, type Register Customer Payments, and open Page 268.
2. Review the list of open customer documents. Locate the rows for Customer 10000, Customer 20000, and Customer 30000.
3. In the Date Received column, enter the deposit date. Adjust Amount Received if any payment was partial.
4. Select the Payment Made checkbox for all three customer rows.
5. In the action bar, click Process -> Post as Lump Sum Payment.
6. Confirm the system prompt: "Do you want to post the payments as a lump sum?" Click Yes.
7. Navigate to Bank Account Ledger Entries (Alt+Q -> type Bank Account Ledger Entries) and observe that exactly one consolidated entry exists for the deposit total, while three discrete customer ledger entries have been marked as closed.

---

Common Configuration Pitfalls & Exam Traps

• Pitfall 1: Attempting to Post an Unprinted or Unexported Line. If a Payment Journal line has Bank Payment Type = Computer Check and the user attempts to post before printing, Business Central throws an error: "Check Printed must be Yes in Gen. Journal Line...". Similarly, if set to Electronic Payment, attempting to post prior to generating the bank file fails.
• Pitfall 2: Confusing Check Void with Financial Void. Executing Void Check in the payment journal only voids an unposted check document. If an issued check has already posted to the General Ledger and Bank Account, running Void Check is impossible; the user must navigate to Check Ledger Entries and execute Financial Void, which generates formal reversing financial entries.
• Pitfall 3: Missing Realized Currency Accounts. When posting a foreign currency cash receipt applied to an invoice, Business Central aborts posting if the underlying Currency card lacks an assigned Realized Gains Account or Realized Losses Account.
• Pitfall 4: Individual vs. Lump Sum Deposit Mismatches in Bank Rec. Choosing Post Payments instead of Post as Lump Sum Payment in the Payment Registration window creates multiple small bank ledger entries. When reconciling against a single lump-sum line on the monthly bank statement, automatic reconciliation rules will fail to match on amount unless manually grouped.