Understanding and testing training discounts

Where is a discount applied?

Bookelio applies the rules of the pricing group linked to the course. The starting price is the date-specific price when one is entered; otherwise, it is the course price. The discount applies to that unit price excluding VAT.

When several participants register, the unit result is applied to the number of participants. The final amount then takes into account any manual adjustment and the VAT applicable to the customer.

Access: Dashboard → Trainings → Pricing groups for configuration, and the discount simulation tool on the same page to explain a case. Prepare courses linked to the correct group and a customer record with a reliable email address.

Configuring clear rules

1. Open pricing group management and create or edit the group you need.
2. Give the rules explicit names so you can recognise the result in a registration.
3. Choose a percentage discount or a fixed amount.
4. Enter the relevant conditions: history, advance-booking lead time and/or training cut-off date.
5. For a history condition, choose the counting method, threshold and which dates may count.
6. Check that the rule is active, then save.
7. Select the corresponding group in the training record.
8. Test several scenarios before relying on this rule for new registrations.

A rule can combine several conditions. In that case, all of them must be satisfied. A rule with no history condition, no advance-booking requirement and no cut-off date is not applied simply because a discount amount is entered.

Available conditions

Number of dates, days or hours

History can be assessed using three measures:

• the number of distinct training dates;
• the sum of durations in days;
• the sum of durations in hours.

The same date counts only once, even when the same customer has registered several participants. The date for which the new price is being calculated is excluded from its own history.

Days and hours come from the durations entered in Bookelio: the date-specific duration takes priority, followed by the general course duration. A missing value contributes zero. Duration is not automatically inferred from the gap between the start and end dates.

Time window and group

Past-day and future-day limits are calculated around the training date being tested, not around the day you open the simulator. The boundaries are inclusive. A limit left blank imposes no boundary on that side.

The rule may count only dates in the same pricing group, only dates assigned to a pricing group, or a broader history, depending on the selected options. A known customer registration may therefore be excluded from a rule because it belongs to another group or falls outside its time window.

Advance booking and cut-off date

Advance booking compares the registration date with the training date. If the rule requires at least 30 days' notice, a registration made sufficiently early satisfies that condition; a late registration does not.

The cut-off applies to the training date. A course scheduled on the cut-off day remains eligible; one after that date does not. Do not confuse this condition with a booking deadline: it is the advance-booking lead time that compares registration with training.

Which history is actually taken into account?

The usual calculation looks for registrations associated with the billing customer's email address, ignoring case, within the current organisation. The participant's address is not the identifier used for that search.

A date must have at least one completed payment on a linked request to enter that history. This does not necessarily mean the entire registration has been paid: an actually recorded first instalment may satisfy the criterion. Conversely, an unpaid payment request alone is not enough.

Without a billing email address, history conditions do not find past registrations in the same way. An advance-booking-only rule may still apply, since it does not depend on history.

The calculation engine does not use attendance as proof of payment. 'Has attended', 'has a registration' and 'has a completed payment' are therefore three separate checks.

Only one discount is selected

Discounts do not stack. Among eligible rules, Bookelio chooses the one producing the highest discount amount. If amounts are equal, the rules' order breaks the tie. The discount is capped at the starting price: it does not make that price negative.

Fictional example: a date costs €200 excluding VAT. The customer qualifies for a 10% discount, worth €20, and a fixed €30 discount. The fixed discount is selected and the price becomes €170 excluding VAT. The two rules do not produce a €50 discount.

For two participants, that result is €340 excluding VAT before any manual adjustment and VAT calculation. The discount simulator itself shows the unit result.

Testing a scenario without changing registrations

The simulator is a read-only debugging tool. It reuses the discount calculation; it does not create a registration, a payment or a real new date.

1. Open the simulator from Trainings.
2. Select a customer. The dates in their history are selected by default.
3. Choose a catalogue date as the basis for the scenario. It supplies the course's price and rules.
4. If needed, change the simulated training date and registration date.
5. Tick or untick dates in the history to compare different assumptions.
6. Use the all-dates view to add hypothetical dates from the catalogue.
7. Read the calculation and the details of each rule. The result updates when the scenario is valid.

Moving the simulated date does not reschedule the actual session or move other dates in the history. This lets you compare, for example, a registration today with an earlier registration without changing the schedule.

Selected does not mean counted

All the customer's dates may be ticked initially, but normally only those meeting the payment criterion enter the calculation. The selection represents your scenario; each rule still applies its group, time-window and threshold conditions.

The option to treat dates as paid is only a debugging assumption. Enable it to test the effect of future payments or artificially added dates. It does not mark any payment as completed. Disable it to compare the scenario with the situation actually recorded.

The history reset and deselection actions let you quickly return to the customer's dates or start again with an empty history.

Reading the result details

The summary shows the initial price, discount and reduced price excluding VAT, along with the pricing group. Rules are shown as selected, eligible or rejected.

An eligible rule may not be selected if another offers a better discount. For a rejected rule, check the reason: inactive rule, threshold not reached, insufficient advance notice, cut-off date exceeded or incomplete configuration.

The details also show the counted value, threshold, time window, group scope and dates actually counted. This list explains why three ticked dates may produce only one eligible date.

Explaining a difference from a registration

Check, in turn, the billing customer and their email address, the date used, the session-specific price, completed payments, durations, pricing group and registration date. Disable any payment assumptions before comparing.

Finally, the simulator does not replace the full registration preview: it does not calculate the customer's VAT, the final number of participants or an amount excluding VAT entered manually. Use Registrations and certificates to check the amount actually requested.