Forward Compatibility: Trial Balance and Journal Entry Reporting
Describes how Forward Compatibility supports Trial Balance and Journal Entry reporting by using generated Credit Memos, Debit Memos, and Application objects as the primary financial sources, and outlines core principles, reporting requirements, legacy-to-IS mappings, and key implementation considerations.
Trial Balance Reporting (FNR) and Journal Entry reporting define how legacy adjustments and payments/refunds map to financial reporting. Under Forward Compatibility, generated Credit Memos, Debit Memos, and Application objects serve as the primary financial source for reporting.
Core principle
Legacy objects are user entry points; CM/DM/Application objects are the main financial explanation sources. One business event should be posted exactly once.
Trial balance requirements
Trial Balance reporting must satisfy the following requirements:
- Invoice Balance must include the impact of generated Debit Memos
- Credit Balance must not be collected again under the legacy CBA view
- Payment and Refund results must be explained through Application structures
Journal entry requirements
Journal Entry reporting must follow these requirements:
- Legacy transaction types must expand to corresponding Invoice Settlement (IS) posting types
- No duplicate posting of legacy and IS objects
- CM/DM/Application are primary Journal Entry sources
- Migration/backfill data separated from ordinary daily transactions
Legacy to Invoice Settlement mapping
The following table depicts the legacy to Invoice Settlement mapping:
Legacy entry | Generated IS result | FNR source |
|---|---|---|
Credit IA |
Credit Memo + CM Application |
CMI + CMAI |
Charge IA |
Debit Memo |
DMI |
Credit IIA + tax |
CM + items/tax + CM App |
CMI/CMI Tax/CMAI |
Charge IIA + tax |
DM + items/tax |
DMI/DMI Tax |
CBA (positive) |
Apply/Unapply relationship |
Application |
CBA (negative) |
CM/DM pair |
CM/DM |
Payment (overpayment) |
Payment Application/Unapplied Payment |
PA/PAI |
Best practices
Follow these best practices when implementing Forward Compatibility:
- Continue using legacy APIs: no changes needed to integration code when using Forward Compatibility
- Plan your migration path carefully: the selection cannot be reversed after commitment
- Verify generated CM/DM: review that Credit Memos and Debit Memos are created with correct amounts and accounting codes
- Use Trial Balance and Journal Entry reports from the IS perspective: these show the definitive financial results
- Do not attempt to edit amounts after creation: update operations do not allow amount changes
- Plan reverse operations carefully: Unapply and Unpost trigger coordinated reverse-cancellations
Important considerations
Be aware of the following important considerations when implementing Forward Compatibility:
- Migration path selection is irreversible: ensure your organization is aligned on Full Migration vs. Forward Compatibility before enablement
- Custom fields on legacy objects do not propagate to generated IS objects
- Legacy finance accounts remain alongside IS finance accounts—neither is replaced
- Zero-balance Debit Memos represent carrying transactions and are part of ordinary business flow
- Migration data is backfilled separately and excluded from ordinary Trial Balance and Journal Entry processing
- Partial unapply of Credit Memos is not supported; full unapply is required for reverse-cancellation
Support and questions
For additional information about Invoice Settlement Forward Compatibility, contact your system administrator.