17.2 Applying, Unapplying & Reversing Customer/Vendor Entries

17.2 Applying, Unapplying & Reversing Customer/Vendor Entries

Quick Summary: In Microsoft Dynamics 365 Business Central, subledger integrity is maintained through Ledger Application, linking payments, credit memos, and refunds to open invoices in Customer Ledger Entries (Table 21) and Vendor Ledger Entries (Table 25). The underlying accounting activity is tracked within Detailed Customer/Vendor Ledger Entries (Tables 379 and 380). When errors occur, Business Central provides two powerful corrective mechanisms: Unapply Entries, which decouples applied documents and reverses associated realized exchange gains/losses and cash discounts, and Reverse Transaction, which posts an exact mirror reversal in the General Ledger. However, Reverse Transaction imposes rigid guardrails: subledger entries must be unapplied first, and closed fiscal periods or inventory cost postings cannot be reversed.

---

Ledger Application Mechanics: Pre-Posting vs. Post-Posting

Application is the operational process of matching an open credit (e.g., payment or credit memo) against an open debit (e.g., invoice), reducing the Remaining Amount on both entries. When Remaining Amount reaches 0.00, Business Central marks Open = False.

Application Methods in Business Central:

1. Pre-Posting Application (Within Journal Batch)
   ├── Direct Application: Populate [Applies-to Doc. Type] & [Applies-to Doc. No.]
   └── Multi-Entry Application: Action -> "Apply Entries" (Page 61/62)
       └── Select Lines -> Action -> "Set Applies-to ID" (Applies-to ID = Doc No.)

2. Post-Posting Application (From Ledger Entry Lists)
   ├── Open Customer or Vendor Ledger Entries
   ├── Highlight unapplied Payment -> Action: "Apply Entries"
   ├── Highlight Invoice -> Action: "Set Applies-to ID"
   └── Action: "Post Application" (Alt+F11) -> Executes Codeunit 226/227

Method 1: Pre-Posting Application (In Journals)

When preparing lines in the Cash Receipt Journal or Payment Journal, users can link documents prior to posting:

• One-to-One Match: Enter the specific invoice document type and number directly in the Applies-to Doc. Type and Applies-to Doc. No. fields on the journal line.
• One-to-Many Match: Leave Applies-to Doc. No. blank, highlight the journal line, and select Process -> Apply Entries (Shift+F11). In the Apply Customer/Vendor Entries window (Page 61 for Customers, Page 62 for Vendors), select the target invoices and click Process -> Set Applies-to ID. The system populates the journal line's Document No. into the Applies-to ID field and updates Amount to Apply. When the journal is posted, Business Central applies the payments simultaneously.

Method 2: Post-Posting Application (From Ledger Entries)

If a payment was posted as a lump sum or without specifying an application target, both the payment and invoice remain open on the subledger. To apply them retroactively:

1. Open Customer Ledger Entries (Alt+Q -> type Customer Ledger Entries, Page 25) or Vendor Ledger Entries (Page 29).
2. Highlight the unapplied payment entry and choose Process -> Apply Entries (Page 61/62).
3. On the target invoice line(s), choose Process -> Set Applies-to ID. Verify the Amount to Apply (which can be edited for partial payments).
4. Choose Process -> Post Application (Alt+F11). Business Central executes Codeunit 226 (CustEntry-Apply Posted Entries) or Codeunit 227 (VendEntry-Apply Posted Entries), immediately closing or reducing the entries without creating new General Journal lines.

---

The Data Architecture: Detailed Ledger Entries

Master ledger entries (Tables 21 and 25) maintain document header summaries and running balances (Original Amount, Remaining Amount, Open). However, the historical granularity of application lives in Detailed Customer Ledger Entries (Table 379) and Detailed Vendor Ledger Entries (Table 380).

Detailed Ledger Entry Transaction Hierarchy:

[Table 21: Cust. Ledger Entry No. 1001 (Invoice)]
  Original Amount: $1,000 | Remaining Amount: $0.00 | Open: No
      │
      ├──► [Table 379: Detailed Cust. Ledg. Entry 5001]
      │      Entry Type: "Initial Entry" | Amount: +$1,000.00
      │
      └──► [Table 379: Detailed Cust. Ledg. Entry 5002]
             Entry Type: "Application" | Amount: -$1,000.00 | Applied Entry No: 1002

[Table 21: Cust. Ledger Entry No. 1002 (Payment)]
  Original Amount: -$1,000 | Remaining Amount: $0.00 | Open: No
      │
      ├──► [Table 379: Detailed Cust. Ledg. Entry 5003]
      │      Entry Type: "Initial Entry" | Amount: -$1,000.00
      │
      └──► [Table 379: Detailed Cust. Ledg. Entry 5004]
             Entry Type: "Application" | Amount: +$1,000.00 | Applied Entry No: 1001

Detailed Entry Types

Every financial movement that impacts Remaining Amount appends an immutable row to Table 379/380:

• Initial Entry: The original posting of the invoice, credit memo, or payment.
• Application: The settlement link between two entries.
• Unapplied: The negation entry generated when an application is undone.
• Payment Discount / Payment Discount (VAT Excl.): Cash discounts granted during application.
• Payment Tolerance / Payment Discount Tolerance: Small write-offs within tolerance thresholds.
• Realized Gain / Realized Loss: Exchange rate differences recognized upon application.

---

Early Settlement Discounts & Payment Tolerances

Business Central automates prompt payment incentives and handles minor underpayments or overpayments without leaving cumbersome penny balances open.

Cash Discounts (Payment Terms)

Configured in Payment Terms (Page 4 / Table 3):

• Discount Date Calculation: Formula (e.g., 10D) determining the Pmt. Discount Date relative to the invoice Document Date.
• Discount %: Percentage reduction (e.g., 2%).
• General Ledger Setup Controls:
  • Payment Discount Grace Period: An optional grace window (e.g., 3D) added to Pmt. Discount Date. Payments received within the grace period still qualify for the discount.
  • Adjust for Payment Discount: If enabled, posting a payment discount automatically adjusts output/input VAT/tax in accordance with local taxation laws.

Payment Tolerances

When customers underpay an invoice by a small amount (e.g., remitting $998 on a $1,000 invoice due to bank wire deductions), Payment Tolerance allows the invoice to close completely.

• General Ledger Setup Parameters:
  • Payment Tolerance %: Maximum allowable percentage variance (e.g., 1.0%).
  • Max. Payment Tolerance Amount: Maximum absolute currency variance (e.g., $5.00).
  • Payment Tolerance Posting: Directs where variances post: Payment Discount Accounts or dedicated Payment Tolerance Accounts.
• When applied, Business Central validates that the variance is within both percentage and maximum amount ceilings, posts the tolerance difference to the designated G/L account, and closes the invoice (Remaining Amount = 0).

---

Unapplying Entries: Reversing Application Mistakes

When a payment is applied to the incorrect invoice or wrong customer account, users must unapply the transaction before it can be corrected.

Unapply Entries Execution Pipeline:

[Customer/Vendor Ledger Entries]
  │ Select applied entry -> Action: "Unapply Entries" (Page 9)
  ▼
[Unapply Customer Entries (Page 9)]
  │ Review application details, cash discounts, and exchange adjustments
  ▼ Action: "Unapply"
[System Postings via Codeunit 226 / 227]
  ├── Inserts "Unapplied" records into Detailed Cust./Vend. Ledger Entries
  ├── Reverses Realized Exchange Gain/Loss entries in G/L
  ├── Reverses Payment Discount / Tolerance entries in G/L
  └── Restores Remaining Amount and sets [Open = True] on all affected entries

Ledger Consequences of Unapplying

Executing Unapply (Alt+Q -> locate entry -> Related -> History -> Applied Entries or Process -> Unapply Entries):

1. Inserts corrective rows into Table 379/380 with Entry Type = Unapplied.
2. Reopens both documents (Open = True) and restores their Remaining Amount values.
3. Reverses any Realized Currency Gain/Loss General Ledger entries posted during the original application, restoring foreign exchange balances.
4. Reverses any Payment Discount or Payment Tolerance G/L postings.
5. Leaves both entries in their original unapplied state, ready for reapplication to the correct invoices.

---

The Reverse Transaction Utility & Strict Boundaries

When an entire journal posting (such as a miskeyed general journal, bank fee, or incorrect payment journal) is wrong, Business Central provides the Reverse Transaction utility (Process -> Reverse Transaction on Page 20 General Ledger Entries, Page 372 Bank Account Ledger Entries, or via Find Entries).

Reverse Transaction Operational Flow:

[General Ledger Entries / Bank Account Ledger Entries]
  │ Highlight entry -> Process -> "Reverse Transaction" (Page 179)
  ▼
[Reverse Transaction Entries Page]
  │ Validates System Restrictions:
  │ 1. Subledger entries applied? ──────► BLOCKED (Must Unapply first)
  │ 2. Closed fiscal period? ──────────► BLOCKED (Period closed by year-end)
  │ 3. Inventory / Cost adjustment? ───► BLOCKED (Use Credit Memo/Return)
  │ 4. Reconciled in Bank Rec? ────────► BLOCKED (Already cleared)
  │
  ▼ If all validations pass -> Action: "Reverse" or "Reverse and Print"
[Reversal Postings Generated]
  ├── Creates exact mirror entries with opposite signs
  ├── Source Code populated with "REVERSAL"
  └── Sets [Reversed = Yes] on original and reversing records

The Four Non-Negotiable Restrictions on Reverse Transaction

Business Central strictly blocks Reverse Transaction if any of the following four conditions exist:

1. Applied Subledger Entries: If an entry involves a Customer Ledger Entry or Vendor Ledger Entry that has been applied to another document, the reversal will fail with: "You cannot reverse... because entry %1 is applied to an entry." The user must unapply the subledger entries first.
2. Closed Accounting Periods / Fiscal Years: Transactions posted into fiscal years that have been closed using the Close Income Statement routine cannot be reversed.
3. Inventory & Cost Adjustments: Transactions originating from sales invoices, purchase receipts, transfer orders, or inventory cost adjustments cannot be reversed via this tool; they must be resolved using Credit Memos, Return Orders, or Item Revaluation Journals.
4. Posted Bank Reconciliations: Bank Account Ledger Entries that have already been matched and closed in a posted Bank Account Reconciliation cannot be reversed.

---

Application vs. Unapplication vs. Transaction Reversal

---

Step-by-Step UI Execution Workflows

Workflow A: Retroactively Applying an Unapplied Customer Payment

1. Press Alt+Q, type Customer Ledger Entries, and select Page 25.
2. Filter for Customer 10000 and locate an unapplied Payment (Remaining Amount equals negative total).
3. In the action bar, choose Process -> Apply Entries (Page 61).
4. Highlight the first target Invoice and select Process -> Set Applies-to ID.
5. Highlight a second target Invoice and select Process -> Set Applies-to ID. Notice that Amount to Apply automatically balances against the payment total.
6. In the action bar, click Process -> Post Application (Alt+F11).
7. Confirm the prompt: "The application was successfully posted." Verify that Remaining Amount is now 0.00 and Open = No on both the payment and the invoices.

Workflow B: Unapplying a Erroneous Application and Reversing the Payment

1. On the Customer Ledger Entries page, highlight the erroneously applied Payment.
2. Click Related -> History -> Applied Entries (Page 63) or select Process -> Unapply Entries (Page 9).
3. On the Unapply Customer Entries page, click Unapply.
4. Confirm the confirmation message: "To unapply these entries, correcting entries will be posted. Do you want to unapply the entries?" Click Yes.
5. Return to Customer Ledger Entries; verify that the Payment and Invoice are now Open = Yes.
6. With the unapplied Payment highlighted, click Process -> Reverse Transaction (Page 179).
7. In the reversal entry overview, verify the reversing lines and click Reverse.
8. Confirm the reversal prompt. Business Central posts offsetting entries with source code REVERSAL and marks Reversed = Yes.

---

Common Configuration Pitfalls & Exam Traps

• Pitfall 1: Attempting Reverse Transaction on Applied Entries. Users frequently attempt to execute Reverse Transaction directly on an incorrect customer or vendor payment. If the payment is applied to an invoice, Business Central aborts with a validation error. The user must always execute Unapply Entries first.
• Pitfall 2: Expecting Reverse Transaction on Posted Sales Invoices. Reversing posted sales or purchase invoices cannot be accomplished via Reverse Transaction. The tool is restricted to general journals, bank entries, and subledger journals. Invoices must be corrected via Credit Memos or Cancel/Correct invoice actions.
• Pitfall 3: Overlooking Foreign Currency Reversal upon Unapply. When unapplying multi-currency entries, administrators often wonder what happened to the realized currency gain or loss. Business Central automatically reverses the realized gain/loss G/L entries during the unapply routine, ensuring currency ledgers return to an exact historical baseline.
• Pitfall 4: Payment Tolerance Exceeded. If an incoming customer payment deviates by more than the configured Payment Tolerance % or Max Tolerance Amount in General Ledger Setup, the system will not close the invoice; it leaves the residual amount open unless manually written off.