6.2 Payment Terms, Payment Methods & Deferrals

6.2 Payment Terms, Payment Methods & Deferrals

Quick Summary: In Dynamics 365 Business Central, Payment Terms govern invoice due dates, early cash discount dates, and cash discount percentages using flexible date formulas (such as 10D, 1M+10D, or CM+10D). Payment Methods define how transactions are settled; when configured with a Balancing Account Type and Balancing Account No., posting an invoice automatically posts and applies a balancing cash or bank payment, closing the invoice immediately. Deferrals automate the distribution of revenue or expenses across multiple accounting periods to satisfy matching principles (ASC 606 / IFRS 15) using Deferral Templates linked to balance sheet holding accounts.

---

Payment Terms: Architecture & Date Formula Syntax

Payment terms establish contractual credit intervals and early payment discount incentives granted to customers or negotiated with vendors. They are configured on the Payment Terms page (Alt+Q -> type Payment Terms).

UI Navigation Path:
Tell Me (Alt+Q) -> Payment Terms

Core Fields on Payment Terms

• Code & Description: Unique identifier (e.g., 1M(8D), CM+10D, NET30) and user-facing explanation.
• Due Date Calculation: A date formula specifying when the invoice becomes due relative to the document date or posting date.
• Discount Date Calculation: A date formula specifying the deadline by which payment must be made to qualify for a cash discount.
• Discount %: The percentage reduction applied to the invoice amount if settled on or before the discount date (e.g., 2.0 for a 2% discount).
• Calc. Pmt. Disc. on Cr. Memos: A boolean toggle that controls whether cash discounts are calculated or reversed when posting credit memos against discounted invoices.

Date Formula Syntax & Evaluation Mechanics

Business Central features a proprietary formula engine for date math. Date formulas combine integer numbers with specific duration abbreviations and positional operators:

Practical Date Formula Calculation Scenarios

Assume an invoice is created with a Document Date of January 15, 2026:

Date Formula Calculation Matrix (Base Date = January 15, 2026):

Formula: 10D     ──► Adds 10 days                  ──► Due Date: January 25, 2026
Formula: 1M      ──► Adds 1 month                  ──► Due Date: February 15, 2026
Formula: 1M+10D  ──► Adds 1 month, then 10 days    ──► Due Date: February 25, 2026
Formula: CM      ──► End of Current Month          ──► Due Date: January 31, 2026
Formula: CM+10D  ──► End of Month, then +10 days   ──► Due Date: February 10, 2026
Formula: CM+15D  ──► End of Month, then +15 days   ──► Due Date: February 15, 2026
Formula: -10D    ──► Subtracts 10 days             ──► Due Date: January 05, 2026

[!IMPORTANT] Crucial Exam Distinction: Notice the critical operational difference between 1M and CM. Adding 1M to January 15 preserves the day of the month, resulting in February 15. In contrast, CM snaps immediately to the final day of the active calendar month (January 31). Therefore, CM+10D evaluates to the 10th of the following month (February 10).

Cash Discounts & Payment Discount Tolerance

When configuring early settlement incentives (such as "2% 10, Net 30"):

• Due Date Calculation: 30D
• Discount Date Calculation: 10D
• Discount %: 2.0

If a customer pays within 10 days, Business Central automatically suggests the 2% discount in the Cash Receipt Journal, posting the difference to the Payment Discount Granted account.

To prevent administrative gridlock when customers pay a few days late or short-pay by minor amounts, consultants configure Payment Discount Tolerance on the General Ledger Setup card:

• Payment Discount Grace Period: Number of days beyond the discount date a payment can still receive the cash discount (e.g., 3D).
• Max. Payment Tolerance Amount: Maximum allowable currency amount difference tolerated during application.

---

Payment Methods: Cash Balancing & Automated Settlement

Payment Methods define the mechanism through which customers pay or vendors are reimbursed. Configured on the Payment Methods page (Alt+Q -> type Payment Methods), they can be assigned to customer/vendor master records or overridden on document headers.

UI Navigation Path:
Tell Me (Alt+Q) -> Payment Methods

Core Fields on the Payment Method Record

• Code & Description: Identifier (e.g., CASH, CHECK, BANK, EFT) and description.
• Balancing Account Type: Specifies the account category for automatic settlement: G/L Account or Bank Account.
• Balancing Account No.: Specifies the specific general ledger account (e.g., Petty Cash) or Bank Account Card used to offset the invoice.
• Direct Debit & Direct Debit Pmt. Terms Code: Used for SEPA / ISO 20022 direct debit mandate collections.
• Pmt. Export Line Definition: Links payment processing to electronic export format definitions (such as NACHA or SEPA Credit Transfers).

The Automatic Balancing Cash Settlement Mechanism

In standard accrual accounting, posting a sales invoice debits Accounts Receivable and credits Sales Revenue, leaving the Customer Ledger Entry with an Open = Yes status and a remaining balance to be collected later via Cash Receipt Journal.

However, when a Payment Method has a Balancing Account Type and Balancing Account No. populated:

Sales Invoice Posting with Balancing Account Defined:

Step 1: System posts standard invoice entry:
        Debit:  Accounts Receivable (Customer Ledger Entry created)
        Credit: Sales Revenue (G/L Entry)

Step 2: System AUTOMATICALLY generates paired balancing payment entry:
        Debit:  Bank Account / Cash Account (Balancing Account No.)
        Credit: Accounts Receivable (Customer Ledger Entry created)

Step 3: System AUTOMATICALLY applies the payment to the invoice:
        Customer Ledger Entry for Invoice ──► Remaining Amount = 0, Open = NO
        Customer Ledger Entry for Payment ──► Remaining Amount = 0, Open = NO

This automatic settlement eliminates the need for separate cash receipt journals. It is the standard configuration for point-of-sale (POS) registers, credit card transactions, and Cash on Delivery (COD) workflows where payment is collected simultaneously with order fulfillment.

[!WARNING] Consultant Trap: If a consultant mistakenly populates a Balancing Account on standard trade credit payment methods (such as NET30), posting any customer invoice assigned that method will instantly register the invoice as fully paid and closed. Receivables will appear artificially cleared, and cash will be overstated.

---

Deferrals Architecture: Templates & Recognition Schedules

Accounting standards (ASC 606 and IFRS 15) require organizations to match revenues and expenses to the periods in which goods or services are delivered, rather than when cash is exchanged or invoices are processed. Business Central fulfills this requirement via Deferrals.

Deferral Templates Setup

Consultants define amortization schedules on the Deferral Templates page (Alt+Q -> type Deferral Templates).

UI Navigation Path:
Tell Me (Alt+Q) -> Deferral Templates

Calculation Methods Compared

1. Straight-Line: Calculates periodic recognition based on period duration units. If periods are monthly, each whole month receives an equal share, with partial periods prorated.
2. Equal per Period: Takes the deferred total and divides it strictly by the No. of Periods, allocating identical monetary amounts to every accounting period regardless of how many calendar days exist in each month.
3. Days per Period: Divides the deferred total by the total calendar days across the entire schedule, multiplying that daily rate by the exact number of calendar days in each specific accounting period (e.g., February receives 28/365, while March receives 31/365).
4. User-Defined: Allocates zero automated amounts, allowing the user to manually enter custom monetary values per period directly on the document schedule.

Period Description Wildcards (Tags)

The Period Description field supports dynamic substitution parameters:

• %1: Current period number (e.g., 1).
• %2: Total number of periods (e.g., 12).
• %3: Month name (e.g., January).
• %4: Month number (e.g., 01).
• %6: Original line description from the purchase or sales document.

Example Template String: Deferred Exp %6 Period %1 of %2 (%3)
Evaluates to: Deferred Exp Insurance Policy Period 1 of 12 (January)

---

Document Deferral Schedules & Posting Preview

Deferral templates can be linked as defaults on G/L Account cards, Item cards, or Resource cards. When an item or account with a linked deferral template is selected on a Sales or Purchase line, the Deferral Code populates automatically.

Document Line Flow:
Sales / Purchase Document Line -> Action: Line -> Deferral Schedule

Modifying Deferral Schedules Prior to Posting

On any unposted document line containing a Deferral Code, selecting Line -> Deferral Schedule opens the Deferral Schedule subpage. From this window, users can:

• Adjust the Start Date or No. of Periods.
• Change the total deferred percentage.
• Manually edit individual periodic amounts or descriptions.

Posting Mechanics & G/L Entry Generation

Consider a $12,000 annual insurance expense entered on a Purchase Invoice dated January 01, 2026, using a 12-period Straight-Line deferral template starting at the Beginning of Period:

Accounting Entries Generated upon Invoice Posting:

Initial Posting on Invoice Posting Date (01/01/2026):
  Debit:  Prepaid Expenses (Balance Sheet Deferral Account)  $12,000
  Credit: Accounts Payable (Vendor Control Account)          $12,000

Amortization Schedule (12 G/L entries created across future periods):
  Date 01/01/2026: Debit Insurance Expense $1,000  |  Credit Prepaid Expenses $1,000
  Date 02/01/2026: Debit Insurance Expense $1,000  |  Credit Prepaid Expenses $1,000
  Date 03/01/2026: Debit Insurance Expense $1,000  |  Credit Prepaid Expenses $1,000
  ... [Repeated monthly through December 01, 2026] ...

[!TIP] Auditing with Preview Posting: Before committing a document with deferrals, always execute Preview Posting (Action Bar: Posting -> Preview Posting). This allows the consultant to inspect the G/L - Item Ledger Relation and G/L Entry records to confirm that entries are distributed across future accounting periods as intended without committing transactional changes to the database.