Rules in Mayday Recharger describe the logic behind how transactions are recharged between your entities. It's a simple process to create the rules, but it’s important to do this with care. Mistakes in your rules can lead to mistakes and oversights in your recharge calculations, and these could cost you more time further down the line.

There are two types of rules in Recharger:

  • Expense rules dictate how expenses incurred by the entity are recharged to other entities in the recharge group

  • Revenue rules dictate how other entities in the recharge group receive revenue from income generated by the entity

We'll look at these two in more detail below.

Recharger creates two "Don't recharge" rules by default for each entity in the recharge group. These apply to all transactions in that entity and won't recharge them to any other entity in the group. You can override these rules, or remove them completely, by creating rules which supersede them.


Expense Rules

You can start creating an expense rule using the "Add new Expense Rule" button:

This takes you to the create expense rule page:

There are three types of expense rule you can create:

  • At Cost: The whole transaction value is recharged

  • Cost plus: The whole transaction value is recharged, plus a fixed percentage on top. If you choose this option, two additional inputs will appear:

    • One asks you to define the percentage which should be added to the value of the transaction

    • Since that additional percentage is revenue for the entity, you'll also need to specify what account code that revenue should be assigned to

  • Don't recharge (expenses): The transaction is not recharged anywhere

Once you've chosen the type of rule you're creating, you'll need to set up the transaction matchers. This is described in the Transaction Matching section below.


Revenue Rules

You can create a new revenue rule with the "Add new revenue rule" button:

This will take you to the create revenue rule page:

There are two types of rule you can create here:

  • Percentage of Revenue: A percentage of the revenue generated will be passed to other entities as income. Since the percentage is a cost to the entity which generated the revenue, you'll also need to specify the account code that cost should be assigned to

  • Don't recharge (revenue): Other entities won't be able to receive any income from matching transactions

Section 6 lets you define which other entities should receive revenue from revenue rules:

You can add whichever entities are required using the "+ Add another entity" button. The figure you enter in the "% of Revenue" column is what percentage of the transaction's value will be recharged. Finally, the last column is the account code the revenue will be assigned to in that entity.

Once you've chosen the type of rule you're creating, you'll need to set up the transaction matchers. This is described in the Transaction Matching section below.


Transaction Matching

For both Expense and Revenue rules, you can define parameters to configure exactly which transactions in that entity the rule will be applied to.

Make this the Default Rule

The first option is to apply the rule to all transactions under that entity. Choosing this will mean the rule becomes the default rule for that entity, and it will be applied to all transactions which do not match other rules you've configured. You can only have one rule with this option set - if you wish to change which rule that is, you'll need to edit that rule's configuration first.

Recharge Specific Transactions

The second option is to define matchers to tell Recharger how to identify the right transactions for this rule. You can define as many of these as you'd like, and configure whether to match all or any of them:

  • Choosing all means that a transaction must match all of the defined criteria in order to have the rule applied to it

  • Choosing any means that a transaction needs only to match one of the defined criteria in order to have the rule applied to it

You can create matchers based on the following transaction properties:

  • Account code matches transactions that are (or are not) in one of the specified account codes

  • Tracking category matches transactions that are (or are not) in one of the specified tracking categories

  • Contact matches transactions that have (or do not have) one of the specified contacts assigned

  • Line Item Description matches transactions that contain (or do not contain) the specified text in their description

  • Reference matches transactions that contain (or do not contain) the specified text in either the narration field from a journal or the invoice reference

In the event that a transaction matches more than one rule, Recharger will pick one of the rules based on a set precedence order, shown at the bottom of the page.


Configuring the Apportionments

Once the transaction matchers are set up, you can define how the matched transactions will be apportioned between other entities in the recharge group. There are two ways of doing this.

Pre-defined Apportionments

You can use the Apportionments page to define commonly-used apportionments. Doing this means you'll only need to update them in one place if they change in the future. See "Apportionments" for more info.

When you choose a pre-defined apportionment, the list of entities and the numbers will be pre-filled for you. You only need to set the account codes: this is where the cost from this recharge rule will be posted in that particular entity's accounting system.

Custom Apportionment

Choosing "Custom" gives you much more flexibility in defining the apportionments. You can choose whichever other entities you'd like from your recharge group, and then adjust the apportionment percentages using the apportionment & "total apportionment units" boxes.

You will need to set the account codes: this is where the cost from this recharge rule will be posted in that particular entity's accounting system.


Conflict Resolution

In the event that a transaction matches more than one rule, Recharger will pick one of the rules based on the following precedence order:

  1. Line Item Description: if the transaction matched a rule based on its description, that rule will be applied

  2. Reference: otherwise, if the transaction matches a rule based on narration, that rule will be applied

  3. Contact: otherwise, if the transaction matches a rule based on the contact assigned to it, that rule will be applied

  4. Account Code: otherwise, if the transaction matches a rule based on the account code it is assigned, that rule will be applied

  5. Tracking Category: otherwise, if the transaction matches a rule based on the tracking category assigned to it, that rule will be applied

  6. Default: finally, if no other rules match, the transaction will have the default "Apply all" rule applied to it

Did this answer your question?