Regular Invoice Settlement vs. Forward Compatibility
Compare Regular Invoice Settlement and Forward Compatibility to choose the right migration approach, including how each handles legacy objects, integrations, and negative invoices.
Zuora provides two migration approaches to Invoice Settlement. Understanding the differences helps you determine the right strategy for your organization.
Aspect | Regular Invoice Settlement | Forward Compatibility Invoice Settlement |
|---|---|---|
Legacy API entry points | Fully deprecated after migration | Remain active and supported |
Legacy objects (CBA, IA, IIA) | Converted and replaced by IS objects; not accessible after migration | Coexist alongside generated IS objects; remain accessible |
Object mapping | One-to-one conversion: CBA → Credit Memo or Application; IA → Debit Memo or Credit Memo; IIA → Invoice Item Settlement | Legacy objects remain as entry points; new IS objects are generated in parallel |
Finance accounts | Legacy finance accounts are replaced by IS finance accounting | Legacy and IS finance accounts coexist; neither replaces the other |
Custom fields | Custom fields on legacy objects do not transfer; must be recreated on IS objects if needed | Custom fields remain on legacy objects only; do not propagate to generated IS objects |
Negative invoices | Not allowed to be created; negative invoices are converted to credit memos during migration | Allowed and treated as legal documents that customers can still create even when IS is enabled |
Integration code changes | Required: APIs must switch from legacy to IS endpoints after migration | Not required: Legacy APIs continue to work; system maintains consistency automatically |
Migration timing | One-time migration event; cutover to new IS objects | Gradual adoption through Invoice Settlement Harmonization; phased coexistence |
Trial Balance & Journal Entry reporting | Uses only IS objects (Credit Memos, Debit Memos, Applications) | Uses generated IS objects as primary source; legacy objects visible for reference |
Reverse entry points (Unapply, Unpost) | Operates on IS objects only; legacy adjustments no longer accessible | Triggers coordinated reverse-cancellation across legacy and IS objects |
Best for | Organizations ready for full transition; no need for legacy compatibility | Organizations needing gradual adoption; maintaining legacy integrations; staged migration |
Practical example: Negative invoice handling
One key difference between the two approaches is how negative invoices are treated:
Invoice Settlement: Negative invoices are not allowed to be created after Invoice Settlement is enabled. During migration, all existing negative invoices are converted to credit memos. After the migration, customers cannot create new negative invoices; they must use the Credit Memo feature instead.
Invoice Settlement Forward Compatibility: Negative invoices remain legal documents that customers can continue to create even after Invoice Settlement is enabled.
This difference makes FC ideal for organizations that have established workflows around negative invoices and want to transition to Invoice Settlement without disrupting those workflows.