Skip to content

Configure The Rule Engine - Decisions tree

The engine rule uses a decision tree to determine how an invoice should be processed. Each decision in the tree is based on a series of criteria grouped into logical groups. These groups define how the system evaluates an invoice and what credit decision status it should receive.

The decision tree is made up of Groups and Branches.

A Group is a node in the decision tree. Each Group:

  • Contains one or more criteria to be evaluated.
  • Has two possible outcomes:
    • True branch: taken if all criteria pass.
    • False branch: taken if one or more criteria fail. The failing criteria are also kept as messages, see Messages when criteria fail.

Each criterion defines a condition that must be met by the invoice. For example:

  • Invoice amount > 1000
  • Client is activated
  • Credit rating is A,AA,AAA

What each criterion checks, and where its value comes from, is described in the Rule engine criteria reference.

For each criteria you can set

  • If no value, allow criteria to pass?
    • If value of the criteria is not defined, you can choose if you like to continue.
      • Exampe, if credit rating doesn’t exist.
      • The value 0 is not considered as no value, except for the client’s overdrawn and expired ledger maximums and the system debtor’s expired ledger limit. See Rule engine criteria reference.
  • If fail, allow financing?
    • If this is “Yes”, an operator can finance an invoice that fails this criterion by moving it forward on purpose. See Overriding a failed criterion.
    • It only works when someone finances the invoice by hand, by dropping it on Finance in the Decisions column of the Invoice Factoring board. Automatic flows never override a failed criterion.
    • Only set this to “Yes” in the very last group
      • When someone moves an invoice forward on purpose, a criterion set to “Yes” counts as passed in every group the invoice goes through, not only the last one. If it is set to “Yes” in a “middle group”, that criterion is considered to pass and the invoice might end up in the True branch. It will override the path and go to a different direction.

All criteria within a group must be True for the group to pass.

Each criterion also has an Error message. See Messages when criteria fail.

  1. The system starts with the first Group (the Start Node).
  2. All criteria in that group are evaluated.
  3. Based on the result:
    • If all criteria pass, the True branch is followed.
    • If any criteria fail, the False branch is followed.
  4. Each branch can lead to:
    • Another Group, or
    • A final credit decision status outcome.

If a Group has no branch defined for the True or False outcome:

  • You can set a credit decision status referred as “Swimlane: If true” or “Swimlane: Is false” directly within that Group.
  • You can also decide if you want to Finance directly.
    • If the choosen swimlane is the Final decision swimlane you can choose an action
    • “Finance with recourse” will set the invoice to use recourse and override existing recourse
    • “Finance without recourse” will set invoice to not use recourse and override existing recourse
    • “Finance” will use the recourse that is already defined on the invoice
  • When the decision process reaches that point, the invoice will be set to the defined swimlane or financed if swimlane of final decision is set.
    • If a swimlane of External financing is set for AROS_KAPITAL, we will automatically send the invoice to AROS_KAPTIAL.
    • If another External financing swimlane is set that does not include AROS_KAPITAL. We will set Pending as default. The external financier need to get invoices in the specific swimlane to be able to proceed.

For example:

  • If the True branch has no next group and is configured with “Ready for approval,” the invoice will be end up in Ready for approval swimlane or Financed if “Final decision” swimlane is set.
  • If the False branch has no next group and is configured with “Rejected,” the invoice will be end up in Rejected.

The very last group within the flow is considered as the Final outcome.

  • When last group is evaluating the criterias and all passes. It will get financed if swimlane “Final decision” is set or it will end up in another swimlane that is defined.
  • All criterias that has been checked on previous groups will not be considered in the Final outcome.

For example

  • If the first group is checking “Client Global Credit Limit” is true and invoice exceed the credit limit → It will go to False branch if there is a defined one.
  • In the False branch you are checking “Invoice value” > 1000 and it passes. If swimlane “Final decision” is set in the group. It will get financed.
    • Why? You are checking in the first group, it fails and it goes to False branch. Then it succeed and Finance is set. It will get financed even if “Client Global Credit Limit” has failed. Its only the last group that decide the outcome. The other groups are just branching.

When an invoice is financed, the tree is followed from the first group until it reaches an end group, a group with no next group on the branch taken. If all criteria in that end group pass, financing is approved, whichever branch led there.

  • Every end group that can approve financing should contain the limit criteria you rely on, for example Client Global Credit Limit and System Debtor Global Credit Limit. A limit checked only in an earlier group does not stop an invoice that reaches a different end group, and an end group without the limit criteria can approve financing over the limit.
  • The rule engine job, which places invoices in swimlanes, and the finance action each follow the tree from the first group. If data changes between the two, for example because another invoice used up a limit, they can take different paths.

Each criterion has an Error message. When an invoice is evaluated, the message of every failing criterion is collected, in every group the invoice goes through. That includes the criterion that sent the invoice down a False branch. The messages are cleared when the invoice passes the tree.

  • There is no setting to hide the message of a single criterion.
  • The system setting ENGINE_RULE_LOG_LAST_GROUP_ONLY limits the messages to the failing criteria of the last group. It is off by default.

The rule has the option Include credit invoices in validation, ticked by default. On the Decision tree tab it is next to the Edit switch, and you change it in edit mode and save it with Save. On the Decision list tab it is part of the rule’s settings.

  • Ticked: credit invoices are evaluated against the rule like any other invoice.
  • Not ticked: credit invoices skip the rule engine. The rule engine job leaves them alone, and financing one passes without any criterion being checked, even when the debtor is not allowed financing.

When a user finances an invoice from the Invoice Factoring board and it fails the rule, the invoice is not financed. A window titled Failed to move invoices lists it. What the user can do next depends on the criteria that failed and on the user’s rights.

What failed Where the invoice is listed What the user can do
Only criteria with If fail, allow financing? set to “Yes” Blocked invoices Move it forward with the arrow in the Move forward column, or use Move all
At least one criterion set to “No”, and the user has the override right Blocked invoices The same
At least one criterion set to “No”, and the user has no override right Failed invoices Nothing: the reasons are listed and the invoice stays where it is
  • Only the user who tries to finance the invoice sees the window. It does not appear when someone else, or the rule engine job, runs the invoice.
  • Moving forward as a user without the override right passes the criteria set to “Yes” and still evaluates the others.
  • Moving forward as a user with the override right skips the evaluation altogether, so every failed criterion is overridden. The evaluation behind the approval is flagged as overridden.
  • Overriding every failed criterion needs a right. To stop a user from doing it, remove the right from the user’s roles. See Rights, roles and users and the rights catalogue.

While a decision tree is in edit mode, financing is blocked for the invoices of the client it belongs to. Financing fails with the message “Engine rule customization is in progress. Please finish editing the engine rule before proceeding.”, and the rule engine job leaves the invoices alone. A warning on the Decision tree tab tells you.

Finish the edit with Save on the Decision tree tab. Financing works again as soon as the tree is saved.

Open the client, choose the Financing tab and find the Rules section. The table there has Enabled, Approve Below and Verification Rate for the client.

When a financed invoice is activated, it is approved automatically, without waiting for a decision, when all of these hold:

  • financing is allowed for the system debtor, the client debtor and the client (Allow financing, and Enabled for the client)
  • the client’s credit limit and the debtor’s credit limit leave room for it
  • the invoice amount is below Approve Below
  • the invoice is not picked for manual verification. Verification Rate is the percentage of such invoices that are picked, so a rate of 0 picks none and a rate of 100 picks all.

Larger invoices, and invoices that are picked, wait for a decision. Set Approve Below to 0 to always get a decision.

Criteria that say (with recourse) or (without recourse) check only that kind of limit, and only when the invoice would be financed that way. Otherwise the criterion is skipped and counts as passed. When the rule engine job evaluates the invoice, which way it would be financed is decided by the end group’s action (FINANCE WITH RECOURSE or FINANCE WITHOUT RECOURSE) when the group has no next group on its True branch, and by the invoice’s current Use Recourse setting in other groups. When someone finances the invoice, or finances invoices in bulk, the recourse requested for that financing decides in every group, and the end group’s action does not. The requested recourse is the one chosen in the action, or else the invoice’s Use Recourse setting.

If a with-recourse limit check sits in a group before the end group that sets recourse, it is skipped while the invoice has no recourse and evaluated once it has. Each run of the rule engine can then change the recourse setting and move the invoice between swimlanes. Put the recourse limit criteria in the end group that sets the recourse, and run the rule engine once.

Start Group: Criteria:

  • Invoice amount > 1000
  • Client is activated

If True → Go to Group 2 If False → Set swimlane: Rejected

Group 2: Criteria:

  • Invoice age < 30 days

If True → Set swimlane: Ready for approval If False → Set swimlane: On Hold

  • If amount > 1000 and clients activate and invoice < 30 days → Approved
  • If amount > 1000 and clients activate but invoice ≥ 30 days → On Hold
  • Otherwise → Rejected

Start Group: Criteria:

  • “Client Global Credit Limit” is true
  • Client is activated

If True → Set swimlane: Ready for approval If False → Go to Group 2

Group 2: Criteria:

  • “Invoice value” > 1000

If True → Set swimlane: Final decision and Financed directly If False → Set swimlane: On Hold

  • If “ Client Global Credit Limit” == false and clients activate and “Invoice value” > 1000 → Financed Approved
  • If “ Client Global Credit Limit” == true and clients activate → Ready for approval
  • Otherwise → On Hold
  • A Group evaluates all its criteria together.
  • All criteria must pass for the True branch to be taken.
  • If any criteria fail, the False branch is taken.
  • The tree continues until a status is reached.
  • You can define a status directly in any Group if no further branches are needed.

To avoid configuring these rules manually for every single client, you can use Client Templates. See Client templates for what a template copies and how to push a change to the clients that use it.

  1. Go to Global Settings > Client Templates.
  2. Create a “New Globe Template.”
  3. Configure the Engine Rules (List or Tree) on the template.
  4. When registering a new client, select this template to automatically apply the pre-set rule logic.
  5. Note: If you update a template later, you can push the changes to all connected clients.