5.3 Journal Entry, the One-Voucher Rule, Validation & Posting
Key Takeaways
- Journal validation can be run before posting to surface dimension, account structure, and balance errors without committing the voucher.
- 'Post and transfer' posts the vouchers that pass validation and moves failing vouchers to a new journal instead of blocking the whole batch.
- Subledger settlement controls on the journal determine whether customer or vendor transactions are settled during posting.
- The one-voucher rule governs whether all lines share a voucher, which affects both balance validation and downstream ledger settlement matching.
5.3 Journal Entry, the One-Voucher Rule, Validation & Posting
Quick Summary: Efficient journal processing in Microsoft Dynamics 365 Finance demands mastery over transaction entry mechanics, validation routines, error resolution workflows, transaction reversals, and external spreadsheet integration. Functional consultants must understand how to enforce the One-Voucher rule, recover from posting failures using Post and Transfer, automate period-end accrual reversals, configure Storno (correction) postings, and leverage the Microsoft Dynamics Office Add-in for high-volume Excel-based journal management.
1. General Journal Entry & Data Modeling
General journals record financial adjustments, intercompany transfers, payroll accruals, and subledger clearing transactions.
Navigation
- Path:
General ledger > Journal entries > General journals
Journal Header vs. Lines Architecture
When a user clicks New in the General journals form:
- Journal Header: The user selects a Name (e.g.,
GEN-ADJ). The system generates a Journal Batch Number (e.g.,JB-000450), stamps the current user ID, locks the journal withIn use bystatus during editing, and defaults the configured Offset account and Posting layer. - Journal Lines: The user clicks Lines to access the detailed transaction grid. Lines can be entered using two architectural patterns:
Pattern A: Single-Line Self-Balancing Entry
+---------------------------------------------------------------------------------------------------------+
| Voucher | Date | Account Type | Account (Main-Dim) | Debit | Offset Type | Offset Account |
+---------+------------+--------------+--------------------+------------+-------------+-------------------+
| VCH-001 | 2026-08-31 | Ledger | 610100-001-022 | $5,000.00 | Bank | USMF-OPER (110110)|
+---------------------------------------------------------------------------------------------------------+
Pattern B: Multi-Line Split Voucher Entry (Sharing Voucher ID: VCH-002)
+---------------------------------------------------------------------------------------------------------+
| Line 1: | 2026-08-31 | Ledger | 610100-001-022 | Debit: $3,000.00 | Offset: [Blank] |
| Line 2: | 2026-08-31 | Ledger | 610200-001-022 | Debit: $2,000.00 | Offset: [Blank] |
| Line 3: | 2026-08-31 | Ledger | 110110-001-000 | Credit: $5,000.00 | Offset: [Blank] |
+---------------------------------------------------------------------------------------------------------+
Financial Tags vs. Financial Dimensions in Journal Lines
In modern Dynamics 365 Finance releases, Financial Tags provide a lightweight mechanism for tracking transactional metadata (such as custom Purchase Order references, internal project codes, or employee IDs) on general journal lines without creating new dimension combination records in the database, preventing index bloat and boosting performance.
2. The 'One-Voucher' Rule & Subledger Settlement Controls
A critical architectural topic on the MB-310 exam is the One-Voucher restriction.
General Ledger Parameter Setup
- Path:
General ledger > Ledger setup > General ledger parameters > Ledger tab > Allow multiple transactions within one voucher
+-------------------------------------------------------------+
| Allow Multiple Transactions Within One Voucher |
+-------------------------------------------------------------+
|
+---------------------------------------+---------------------------------------+
| | |
v v v
[ Reject ] [ Accept with warning ] [ Disallow ]
(Strict MB-310 Standard) (Legacy Migration Only) (Hard System Exception)
- Blocks mixing Customer & Vendor - Displays warning toast - Completely blocks saving
- Blocks multi-subledger vouchers - Permits voucher commit - Throws runtime error
Why Microsoft Deprecated Multiple Subledger Transactions in One Voucher
In legacy versions (AX 2012), users could post a single voucher containing multiple customer, vendor, or fixed asset subledger transactions. In Dynamics 365 Finance, this practice causes severe architectural failures:
- Settlement Failures: When cash discounts or partial payments are applied across multiple subledger records in a single voucher, the AR/AP settlement engine cannot determine which subledger line owns the cash discount or realized exchange rate gain/loss.
- Sales Tax Accounting Anomalies: Tax calculations depend on the relationship between an invoice line and a vendor/customer party. Multiple parties in one voucher result in corrupted tax settlement vouchers.
- Foreign Currency Revaluation: Currency revaluation calculates unrealized gains/losses per subledger transaction. Multi-party vouchers cause cross-contamination of revaluation postings.
[!IMPORTANT] Recommended Consultant Pattern: Always set Allow multiple transactions within one voucher to Reject. To record complex settlement transactions between multiple parties (e.g., offsetting a vendor balance against a customer balance), enter separate vouchers and route the offsetting entries through an intermediate Clearing Main Account (
210999 - Subledger Clearing).
3. Voucher Validation, Posting & 'Post and Transfer' Error Handling
Before journal lines can update the General Ledger, they must pass comprehensive validation checks.
Validation Methods
- Validate > Validate: Evaluates account structure rules, financial dimension requirements, debit/credit balancing, fiscal period statuses, and currency exchange rates without committing data.
- Validate > Validate voucher only: Validates only the currently highlighted voucher lines.
- Simulate posting: Runs the complete posting pipeline in memory—evaluating accounting distributions, subledger posting profiles, and tax calculations—without writing records to ledger tables.
'Post' vs. 'Post and Transfer' (Batch Error Recovery)
When posting a journal batch containing hundreds of voucher lines, errors may occur (e.g., a missing dimension, an unmapped sales tax code, or a closed period for one voucher).
+---------------------------------------------------------------------------------------+
| Journal Batch: JB-000500 (100 Vouchers) |
+---------------------------------------------------------------------------------------+
| Click: POST AND TRANSFER |
+-------------------------------------------+-------------------------------------------+
| | |
| 95 Valid Vouchers | 5 Erroneous Vouchers (e.g., Missing Dept) |
| - Account structures valid | - Validation rule failed |
| - Dates in open fiscal period | |
| | |
| v | v |
| +------------------------------------+ | +------------------------------------+ |
| | Posted Immediately to GL | | | Transferred to NEW Journal: | |
| | (Batch JB-000500 Marked Posted) | | | JB-000500-1 (Unposted Draft) | |
| +------------------------------------+ | +------------------------------------+ |
+-------------------------------------------+-------------------------------------------+
- Standard Post: If 99 vouchers are valid but 1 voucher has an error, the entire posting job aborts, and zero vouchers are posted.
- Post and transfer: The system processes all valid vouchers, commits them to the General Ledger, marks the original journal header as posted, and automatically generates a new journal batch (e.g.,
JB-000500-1) containing only the failed voucher lines! Accountants can then correct the invalid lines in the new journal and post them without delaying month-end processing.
A senior accountant is posting a month-end General Journal batch containing 200 vouchers. During posting, 5 vouchers fail validation due to missing mandatory cost center dimensions, while the remaining 195 vouchers are completely valid. The controller cannot delay the posting of the 195 valid vouchers. Which posting function should the accountant use?
A month-end batch of 200 vouchers is posted and five vouchers fail validation because a mandatory cost centre is missing. The controller needs the 195 valid vouchers in the ledger today and wants the failures isolated for correction. Which option achieves this?