Using rules in Mayday Recharger, you can split costs and revenues between account codes or tracking categories both within and between entities.
Pre-defined Apportionments
If the apportionment is going to be used in multiple rules, it can be worth creating it in the "Apportionments" section and then choosing it when you create your rules. A common use case for this is to create a headcount-based apportionment - using the Apportionments section will mean that you only need to update one place if the headcounts change.
To create one, go to the Apportionments section and choose the entity you want to create it for (if you only have a single entity in your group, it should be selected automatically). Click "+ Add new".
Give your apportionment a name so you can refer to it later, for example "Department Headcount".
Next, choose whether to define the apportionment with Units or a Percentage split:
Units are useful for apportionments such as headcount, where the total may change
Percentages are useful for apportionments where the splits are fixed, or where the total does not change, such as the proportion of working hours spent on a project
You can now create all the splits by adding rows to the table underneath. For each, enter the appropriate figure. You can also choose how account codes and tracking categories should be handled - for more information on this, jump to "Account Code and Tracking Category Actions".
Once you're done, hit "Save" to make sure your apportionment is available in the rules page.
Creating a Recharge Rule with an Intra-entity Apportionment
To start, follow the steps in "How Recharge Rules Work" to choose which rule type and configure the transaction matchers. You can then define the apportionments required to split these transactions within account codes and tracking categories in your Xero file.
Before we choose or define our intra-entity apportionment, we can define how much of the transaction should be split. If the rule is working across entities, this step let's us choose how much should be sent to each entity in the group. If we're working with only a single entity, we are defining whether any of the transaction should be "left behind". For instance, you may want to split your transaction between the departments, but always keep 10% behind for management overheads. In this case, we could configure the apportionment such that only 90% of each transaction is applied, as in the following screenshot:
Note how the screen shows you the proportion of the overall cost which will go to the intra-entity splits. Hovering over one of those figures shows how this is calculated:
Once that's done, you can choose from one of your pre-defined apportionments or create a new one. If you'll only need to use your apportionment in the one rule you're creating, then a custom apportionment has the benefit of keeping all configuration in one place. Defining this acts almost exactly like when creating a pre-defined apportionment, so refer to "Pre-defined Apportionments" to learn about the configuration options.
There are two primary differences when creating the apportionment within the rule:
You can only create the apportionment using units, except in revenue rules where you can only use percentages
You can create an intra-entity apportionment for a different entity in your group. If you do this, you won't be able to set Account Code and Tracking Category options - you will be required to enter at least an account code from that entity to use when recharging
Account Code and Tracking Category Actions
You can choose how account codes and tracking categories should be handled. There are two options for the account code and each tracking category:
"Retain" an account code or tracking category will use the original transaction's property when it is recharged
"Set" allows you to define a new value that should be applied to the recharge transaction. For tracking categories, this value can be empty
An example may be useful to see how this works in action. Let's say we have a transaction of £100 in account code 200, with two tracking category values: region is "England" and department is empty.
If we configured our apportionment as below:
Then three transactions would be created when this transaction is recharged:
Amount | Account Code | Region | Department |
£50 | 200 | England | Engineering |
£30 | 200 | England | Finance |
£20 | 200 | England | Management |
Note how the original transaction's account code and region have been used, but a new value for "Department" has been set.
In this scenario:
Two transactions would be created when the recharges are calculated:
Amount | Account Code | Region | Department |
£90 | 40000 |
|
|
£10 | 412 |
|
|
Note how a new account code is used, and the value for "Region" has been removed on the new transactions.