Invoice Settlement Forward Compatibility
Describes how Invoice Settlement Forward Compatibility lets you keep using legacy adjustment APIs while automatically generating and synchronizing corresponding Invoice Settlement financial objects.
Invoice Settlement Forward Compatibility (FC) enables seamless integration between legacy invoice adjustment operations and new Invoice Settlement (IS) financial objects. This documentation guides you through the four key components:
Invoice Adjustments (IA)
Invoice Item Adjustments (IIA)
You can continue operating through familiar legacy APIs while the system automatically maintains consistency with new IS financial explanations. One business event is recorded exactly once, through either the legacy or new perspective, never both.
When enabling Invoice Settlement for your organization, you can use the Invoice Settlement Guiding Agent that walks you through a phased enablement process. This process includes a critical decision point where you select your migration path. For more information, refer to Invoice Settlement Guiding Agent.
To know the differences between Invoice Settlement and Invoice Settlement Forward Compatibility, refer to Regular Invoice Settlement vs. Forward Compatibility.
API Operations by Invoice Settlement mode
The available CRUD operations for legacy adjustments and Invoice Settlement objects vary depending on which Invoice Settlement mode is enabled. Understanding these operational differences is critical for integration planning.
Mode | Legacy Objects (IIA/CBA/IA) | Invoice Settlement Objects (CM/DM) |
|---|---|---|
IS OFF (Invoice Settlement Disabled) | Create, Update, Delete, Read | Not available |
IS ON (Regular Invoice Settlement) | Read only (objects are deprecated and no longer modifiable) | Create, Update, Delete, Read |
IS FC ON (Forward Compatibility) | Create, Update, Delete, Read (using identical API, request payload, and response payload as IS OFF) | Create, Update, Delete, Read (automatically generated from legacy operations) |
Here are key operational insights:
IS OFF: Full CRUD on legacy objects; IS objects not available
IS ON: Legacy objects locked to read-only; all modifications must use new CM/DM APIs
IS FC ON: Legacy APIs fully functional with original request/response formats; system automatically generates corresponding CM/DM objects behind the scenes
Forward Compatibility API behavior
When Invoice Settlement Forward Compatibility is enabled, the most significant operational advantage is API consistency:
Same API endpoints: Create/Update/Delete operations on IIA/CBA/IA use the exact same endpoints as IS OFF
Same request payloads: No changes required to request structures or field mappings
Same response payloads: Responses return in the same format as IS OFF operations
Transparent object generation: After the API call completes, the system automatically generates corresponding CM/DM objects and maintains both legacy and IS data
Key differences summary
Here is a summary of the key differences between Forward Compatibility Invoice Settlement and Regular Invoice Settlement:
Regular IS: Legacy objects are replaced; Forward Compatibility: Legacy objects coexist with new IS objects
Regular IS: Negative invoices prohibited; Forward Compatibility: Negative invoices remain allowed
Regular IS: Integration code must change; Forward Compatibility: Legacy APIs remain functional
Regular IS: Single migration event; Forward Compatibility: Gradual phased adoption
Regular IS: Custom fields don't transfer; Forward Compatibility: Custom fields remain on legacy objects
Regular IS: Clean break from legacy; Forward Compatibility: Smooth backward compatibility
Key principles of Forward Compatibility
Here are the key principles of Forward Compatibility:
Legacy SOAP/API entry points remain active; legacy UI is hidden
Legacy and Invoice Settlement objects coexist; legacy finance accounts are NOT replaced
Generated Credit Memos and Debit Memos are automatically Posted
Amount and accounting code fields are immutable after creation
Custom fields remain on legacy objects only; they do not propagate to generated IS objects
Specific reverse entry points (Unapply, Unpost) trigger coordinated reverse-cancellation
Trial Balance Reporting (FNR) uses generated IS objects as the primary financial source