> For the complete documentation index, see [llms.txt](https://docs.xorosoft.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.xorosoft.com/xoroerp-1/admin/item/rebates-and-promotions/managing-rebates-throughout-the-transaction-lifecycle.md).

# Managing Rebates Throughout the Transaction Lifecycle

Creating a rebate is only the first step in the rebate process. Once a rebate has been configured and activated, XoroERP automatically manages its lifecycle as transactions progress through Sales Orders, Invoices, Returns, Credit Memos, and Vendor Billbacks.

Rather than treating rebates as static discounts, XoroERP continuously evaluates, recalculates, and maintains rebate records throughout the transaction lifecycle while preserving a complete audit trail. This ensures rebate amounts remain accurate even when transaction quantities change, invoices are edited, products are returned, or rebate definitions are modified in the future.

This article explains how rebates behave after they have been created and how XoroERP maintains financial and transactional accuracy.

***

### Invoice Creation and Rebate Calculation

When an Invoice is created, XoroERP automatically determines which rebates are applicable to each invoice line based on the rebate rules configured in the **Rebates and Promotions** module.

If the Invoice originates from a **Sales Order**, the rebate information identified during Sales Order creation is carried forward to the Invoice wherever applicable. However, the rebate amount is **not simply copied**. Instead, XoroERP recalculates the rebate using the **actual quantity being invoiced**, ensuring customers receive rebates only for the items that are actually billed.

After recalculation, the system:

* Determines the qualifying rebate(s) for each invoice line.
* Carries forward the selected rebate from the Sales Order when applicable.
* Recalculates the rebate using the invoiced quantity.
* Records the selected rebate against the Invoice.
* Creates any eligible earned rebate transactions.
* Includes the required General Ledger entries when the rebate configuration requires financial posting.

This process ensures that rebate values always reflect the final financial transaction rather than the originally ordered quantity.

***

#### Example: Partial Invoice Recalculation

Consider the following scenario:

| Transaction          | Quantity |
| -------------------- | -------: |
| Sales Order Quantity | 10 Units |
| Invoice Quantity     |  4 Units |

Although the original Sales Order qualified for a rebate on **10 units**, only **4 units** are being invoiced.

Rather than applying the rebate for all 10 units, XoroERP automatically recalculates the rebate using the **4 invoiced units**.

This prevents customers from earning rebates on products that have not yet been invoiced while keeping rebate balances synchronized with actual revenue recognition.

***

### Sales Order Qualification Date

For Invoices that originate from a Sales Order, rebate eligibility continues to use the **original Sales Order Date** rather than the Invoice Date.

This is particularly important for promotional campaigns that have specific validity periods.

For example:

* Promotion Period: **January 1 – January 31**
* Sales Order Created: **January 30**
* Invoice Generated: **February 5**

Although the Invoice is created after the promotion expires, the rebate remains valid because the qualification is based on the **Sales Order Date**.

This ensures customers receive the rebate that was valid when the order was placed.

***

### Editing an Invoice

Business transactions often change after an Invoice has been created. Quantities may be updated, items may be added or removed, or pricing may change.

Whenever an Invoice containing rebates is edited, XoroERP automatically re-evaluates the rebate for the modified transaction.

Instead of creating duplicate rebate records, the system intelligently compares the previous rebate state with the updated transaction and performs only the necessary adjustments.

Depending on the changes made, XoroERP will:

* Recalculate the rebate using the updated transaction details.
* Reverse rebate amounts that are no longer applicable.
* Create new rebate amounts for newly qualified transactions.
* Preserve rebate records that remain unchanged.
* Prevent duplicate rebate transactions from being created.

This ensures rebate balances remain accurate without requiring manual reconciliation.

***

### Returns, RMAs, and Credit Memos

When products are returned, rebate processing follows the original transaction rather than the current rebate configuration.

Instead of recalculating the rebate using today's rules, XoroERP references the rebate information that existed when the original sale occurred.

This preserves historical accuracy and prevents promotional changes from affecting previously completed transactions.

***

#### How Rebate Reversals Work

Whenever an Invoice-linked return or RMA is processed, the system creates a proportional reversal based on the quantity being returned.

#### Example

Original Invoice

| Quantity Sold | Original Rebate |
| ------------: | --------------: |
|      10 Units |            $100 |

Customer Returns

| Returned Quantity | Rebate Reversal |
| ----------------: | --------------: |
|           2 Units |             $20 |

Because **20%** of the original quantity was returned, **20%** of the rebate is reversed.

The same logic applies regardless of rebate type.

* Partial returns generate proportional rebate reversals.
* Full returns reverse the entire rebate amount.

This approach ensures rebate balances always reflect the customer's final purchase quantity.

***

#### Voiding an Invoice

Invoices that contain rebate activity cannot always be voided immediately.

Before an Invoice can be voided, XoroERP verifies whether dependent rebate transactions already exist.

Examples include:

* Customer rebate balances that have already been applied.
* Vendor Billback claims that have already been generated.
* Related settlement transactions.

If these downstream transactions exist, they must first be unapplied or reversed before the Invoice can be successfully voided.

This validation protects financial integrity by preventing orphaned rebate transactions and ensuring accounting records remain balanced.

***

### Rebate Audit and History

Every rebate generated by XoroERP is fully traceable.

The system maintains a complete audit history so organizations can review how every rebate was calculated, applied, settled, and reversed.

Historical rebate records include information such as:

* Rebate definition used
* Rule Group that qualified the transaction
* Customer
* Item
* Vendor
* Source Sales Order or Invoice
* Source transaction line
* Rebate amount
* Currency
* General Ledger configuration
* Vendor Billback status
* Qualification criteria
* Customer rebate application history
* Reversal history

This information provides complete visibility into every rebate transaction for financial auditing, customer support, and vendor reimbursement purposes.

***

#### Historical Integrity

One of the most important principles of the rebate engine is that **historical transactions are never rewritten**.

If a rebate definition is modified after transactions have already been processed—for example:

* The rebate percentage is changed.
* A qualifying customer is added.
* New Rule Groups are introduced.
* A promotional period is extended.

Only **future transactions** use the updated rebate definition.

Previously generated rebate transactions continue using the rules that were in effect when they were created.

This preserves accounting accuracy and ensures historical financial reports remain unchanged.

***

### Things to Remember

Keep the following rebate behaviors in mind when working with transaction documents:

* Rebates are recalculated using the **actual invoiced quantity**, not the original ordered quantity.
* Sales Order-linked Invoices qualify using the **Sales Order Date**.
* Editing an Invoice automatically re-evaluates rebate eligibility.
* Returns use the **original rebate information**, not the current rebate configuration.
* Partial returns generate proportional rebate reversals.
* Invoices containing settled rebate activity cannot be voided until dependent rebate settlements have been reversed.
* Historical rebate transactions remain unchanged even if rebate definitions are modified later.
* Every rebate transaction is permanently recorded, providing a complete audit trail throughout the rebate lifecycle.

By automatically recalculating rebates while preserving historical accuracy, XoroERP ensures that customer incentives, vendor reimbursements, and financial postings remain synchronized throughout the entire transaction lifecycle.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.xorosoft.com/xoroerp-1/admin/item/rebates-and-promotions/managing-rebates-throughout-the-transaction-lifecycle.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
