Payment terms and methods in Business Central

How Business Central models payment terms, payment methods, payment discounts, and the integration with bank file generation.

Updated 2026-07-03

Two pieces of master data govern how Business Central handles customer and vendor payments: payment terms (when payment is due and what discount applies for early payment) and payment methods (how the payment is made). Configured well, the two collapse what would otherwise be manual reasoning into automatic calculation on every transaction.

Payment terms. A payment term carries:

  • Due Date Calculation — a formula like 30D (30 days), 1M (one month), CM (current month-end), 1M+10D (month-end plus 10 days). Applied to the document date to compute the due date.
  • Discount Date Calculation — formula for the early payment discount cutoff date.
  • Discount % — the percentage discount earned if paid by the discount date.
  • Calculate Pmt. Disc. on Cr. Memos — whether the discount applies to credit memos as well as invoices.

Common payment terms:

  • Net 30 (30D, 0%) — pay within 30 days, no discount.
  • 2/10 Net 30 (30D, 2%, discount date 10D) — pay within 10 days for 2% off, otherwise 30 days net.
  • End of Month + 30 (CM+30D) — pay 30 days after the month-end of the invoice date.
  • Cash on Delivery (0D) — payment with delivery.

Customers and vendors carry a default payment term that flows onto each document; users can override at the line.

Payment methods. A payment method carries:

  • Code and Description — Bank Transfer, Cash, Cheque, Direct Debit, Credit Card, Bank File.
  • Balancing Account — the GL account where the offset posts when a sales invoice with this method is posted. For "Cash" payment, the invoice posts both the AR and the cash GL account in one step; for "Bank Transfer", AR remains open until the bank receipt is recorded separately.
  • Bal. Account Type — GL Account or Bank Account.
  • Direct Debit-related properties — pre-authorisation, mandate references.
  • Payment Export properties — controlling which bank file format applies.

Combined effect. A sales invoice posted with payment term "Net 30" and payment method "Cash" creates the AR ledger entry and immediately posts the cash receipt. The same invoice with payment method "Bank Transfer" creates only the AR entry; the receipt comes later when the bank statement is reconciled or the payment journal posts.

Payment journals. Vendor payments are typically processed through the payment journal — a batch of payment lines selected from open vendor invoices, filtered by due date or payment method, generating a bank file (SEPA, ACH, BACS, Norwegian KID, Swedish SUS, etc.) for upload to the bank. The journal posts the payment, applying it to the original invoices and updating bank balances.

Suggest Vendor Payments. A built-in routine reviews open vendor invoices and proposes which to pay, based on filters: payment method, due date, available cash. The user reviews and adjusts before posting.

Customer Direct Debit. A separate process for customer direct debits generates pre-authorised bank-debit files for customers on direct-debit payment methods.

Configuration discipline. Standardise payment terms — a tenant rarely needs more than 8–12 distinct terms. Same for payment methods — bank transfer, direct debit, credit card, cash, and a few exceptions cover most operations. Resist proliferation.

Related guides