Skip to main content

Invoice nodes

Use these Workflow Designer nodes to customize the invoice business logic for your organization.

Written by Yokoy Team

🌐 Web only | 👤 Yokoy admin with Workflow Designer permissions

🏢 Node use - Professional and Enterprise plan

Some condition, activity, and approval nodes are restricted to Yokoy Professional or Enterprise plans. Your company must have one of these plans to incorporate them in your workflow.

The Workflow Designer uses nodes to determine the business logic applied in processing invoices in Yokoy.

When you create a workflow, you use four types of node:

  • Status nodes: Indicate the document’s status. In other words, these nodes represent Yokoy internal statuses (e.g. Draft, In approval, etc.).

  • Condition nodes: Represent conditional clauses. They are if-else conditions based on specific logic that is either true or false.

  • Activity nodes: Represent actions or tasks behind the scenes in Yokoy.

  • Approval nodes: Complement activity nodes to reproduce the business logic of an approval flow.

Status nodes are common to both invoice and expense workflows. Condition, activity, and approval nodes are specific to each workflow type.

Each status node has a specific combination of nodes that can be placed before and after. The action that can be triggered depends on this combination.

The Workflow Designer allows these combinations for invoice workflows:

Status node

Incoming
​node / action

Outgoing
​node / action

New

  • Start (None)

  • Activity (Submit)

  • Reject (Reject)

  • Draft (Save)

Draft

  • New (Save)

  • Approval (Recall)

  • Ready for export(Recall)

  • In review (Recall)

In review

  • Approval

  • Ready to export (Back to review)

  • Ready to export (Review)

  • Needs revision (Send back)

  • Draft (Recall)

Needs revision

Ready for export

  • Export (Revert)

  • Export

  • Draft (Recall)

  • In review (Back to review)

Exported

  • Export

  • Ready for export (Revert export)

Rejected

  • New (Reject)

  • Draft (Reject)

  • Needs revision (Reject)

  • None

Invoice condition nodes

Condition nodes include conditional clauses for performing the next step in the workflow. The Workflow Designer offers these notes for managing invoices:

Contains PO number

Configure a true/false condition based on whether the invoice contains a purchase order (PO) number selected:

  • True: If the invoice is linked to a PO, e.g. if at least one PO number has been selected in the invoice header.

  • False: If the invoice is not linked to a PO, e.g no PO numbers can be found in the invoice header.

For example, you submit an invoice. If the invoice is associated with a PO, you skip the approval flow and go to In review. Otherwise, it performs a tag approval flow (i.e. all of the approvers on the tag value are required to approve).

Amount validation

Configure a true/false condition based on the amount of the invoice.

In this case, this condition returns:

  • True: The amount condition is met.

  • False: The amount condition is not met.

For example, you set up the logic to tell Yokoy if the invoice is between 10 and 100 CHF to skip the approval flow and go to In review. Otherwise, perform a tag approval flow.

This specific condition comes with three different options:

Option

Accepted value

Description

Lower threshold

Number

This is the lower limit. If the amount is greater, the amount validator returns true. Otherwise, it returns false.

Upper threshold

Number

This is the upper limit. This is the upper limit. It returns true, if the amount is lower than the upper limit. If exceeded, it returns false.

Currency

String

This is the currency you want to use for comparison. It is advisable to use the same company currency. Use ISO 4217 3-digit code.

✏️ Note

If you enter a threshold value, you must enter the currency to be used.

You can define a lower or an upper threshold to check whether the document amount is greater than or less than the specified threshold, or set a lower and upper threshold to check whether the document amount is between a range.

Auto-approve based on supplier condition (Enterprise only)

Configure a true/false condition to determine whether you want to automatically approve invoices from a specific supplier. This condition node is used with Auto-approve an invoice for a certain supplier. If you add one to the workflow, you see a new section in Supplier > Settings. From there, you can configure an auto-approval threshold for the supplier itself. In this case, this condition returns:

  • True: If the invoice is less than the auto-approval threshold set up on the supplier.

  • False: If the invoice is more than the auto-approval threshold set up on the supplier.

Depending on the workflow, the invoice is either Ready for export or In review.

🚧 Caution

If you do not enable supplier auto approval on the specific supplier, it uses the approval flow that you have defined.

True/false condition

Configure a true/false condition based on specific business rules that you determine in JSON format.

  • True: The JSON-specified condition is met (i.e. the property is present on the invoice).

  • False: The JSON-specified condition is not met (i.e. the property is not present on the invoice).

For example, you can use this condition to check for any attribute present on the invoice, such as PO number, custom fields, tag values, etc.

✏️ Note
The True/False condition checks for attributes saved on the invoice (such as custom fields). If you need to check attributes on the object itself, such as whether a custom field has been selected on a tag dimension, use the Custom true/false condition.

JSON rules

You can build complex business rules and serialize them as JSON. The JSON rules are specified in the Rules field of the node options.

These operations are supported:

Accessing data

var, missing

Logic and Boolean operations

if, ==, ===, !=, !== , ! , !! , or , and

Numeric operations

> , >= , < , <=, max, min, +, - , *, /, %

Array operations

map, reduce, filter, all, none, some, merge, in

String operations

in, cat, substr

For example, you can:

Check for custom field on invoice

You can set up a rule to check if there is a specific custom information field value and it is equal to true. If so, it returns true.

  1. Identify the name of the custom information field in the company.

  2. Then add a true/false node and copy and paste this snippet into the Rules field:

    {
      "==": [
        {
          "var": [
            "customInformation.skipApproval"
          ]
        },
        true
      ]
    }

  3. Then you assign the workflow to the legal entity.

✏️ Note - Custom information fields
Custom information fields can only be set up by Yokoy. You may need to open a support ticket if the custom information field you require doesn‘t already exist in your Yokoy implementation or if you don’t know the name (which may or may not be the same as the label shown in the app).

Check for currency mismatch notification

You can set up a rule to check if there is, among notifications, a currency mismatch value and it is equal to true. If so, it returns true.

✏️ Note

You need to have imported POs for the company.

Add a true/false node and copy and paste this snippet into the Rules field:

   {
  "!": {
    "reduce": [
      {
        "var": "notifications"
      },
      {
        "or": [
          {
            "in": [
              {
                "var": "current.title"
              },
              [
                "supplierInvoiceNotification.currencyMismatch.title",
                "supplierInvoiceNotification.multipleCurrencyMismatch.title"
              ]
            ]
          },
          {
            "var": "accumulator"
          }
        ]
      },
      false
    ]
  }
}

Check for account mismatch notification

You can set up a rule to check if there is an account mismatch notification in all the invoice notifications and it is equal to true. If so, it returns true.

Add a true/false node and copy and paste this snippet into the Rules field: 

{
    "some":
    [
        {
            "var": "notifications"
        },
        {
            "==":
            [
                {
                    "var": "title"
                },
                "supplierInvoiceNotification.mismatchAccountNumber.title"
            ]
        }
    ]
}

Check for tax-only line item

You can set up a rule to check if there is at least one tax-only line item in all the line items. If so, it returns true.

Add a true/false node and copy and paste this snippet into the Rules field:

{
   "some":[
      {
         "var":"lineItems"
      },
      {
         "==":[
            {
               "var":"isTaxOnly"
            },
            true
         ]
      }
   ]
}

🚧 Caution

Not all ERP/Finance systems integrations support tax-only line items. Check with Yokoy Customer Success to see if this is possible for your finance system.

Check for invoice business rules

In Yokoy Invoice, you can set up invoice business rules that allow you to check for a list of pre-determined keywords on the document. If the keyword is present, you can define a specific action. For example, you can enter a set value in a specific custom field or select a custom field checkbox.

There are two ways you can use the workflow to check for those cases and route the invoice to a different path: either check for the custom field or check for a specific notification.

  • Check that the custom field is selected/contains a specific value as a result of the invoice business rule action.
    In the example below, you check if the invoice contains the word Iran. If it does, Yokoy selects the custom field checkbox Embargo invoice.
    ​


    In this case, you set up the usual check for custom fields being present on the invoice document with the following code: 

{
  "==": [
    {
      "var": [
        "customInformation.embargoInvoice"
      ]
    },
    true
  ]
}

  • Check for an invoice business rule notification/warning on the invoice document. In the example below, you check for the presence of the keyword notification on the invoice header:
    ​


    In this case, you need to check for the presence of invoice notifications with this code:

{
    "some":
    [
        {
            "var": "notifications"
        },
        {
            "==":
            [
                {
                    "var": "title"
                },
                "supplierInvoiceNotification.keywordsDetected.title"
            ]
        }
    ]
}

Check for invoice statutory requirements

In Yokoy Invoice, you can check for statutory requirements. In other words, Yokoy can check for the presence of attributes that are standard in invoice documents and triggers a specific notification. You can check for the presence of these notifications in your workflow.

For example, you can:

  1. Prevent the invoice from progressing in the workflow if there are any checks that make the invoice invalid according to your purpose. For example, you may want to halt the workflow and return a notification if the invoice has an invalid VAT number, supplier address, and so on.

  2. Move the invoice to Needs Revision status if there are any of these notifications present on the invoice header.

The basic code snippet for setting up this JSON rule is as follows, where you replace the “Notification” with the notification reference. 

{
    "some":
    [
        {
            "var": "notifications"
        },
        {
            "==":
            [
                {
                    "var": "title"
                },
                "NOTIFICATION TEXT"
            ]
        }
    ]
}

Scenario

Notification reference

Customer address missing

supplierInvoiceNotification.missingCustomerAddress

Customer address doesn't match master data

supplierInvoiceNotification.mismatchCustomerAddress

Customer address found in another legal entity

supplierInvoiceNotification.mismatchCustomerAddressCrossLegalEntity

Supplier address missing

supplierInvoiceNotification.missingSupplierAddress

Supplier address doesn't match master data

supplierInvoiceNotification.mismatchSupplierAddress

Check for Non-PO line items

You can set up a rule to check if there is at least one line item with matching status Non-PO. If so, it returns true.

Add a true/false node and copy and paste this snippet into the Rules field:

{
   "some":[
      {
         "var":"lineItems"
      },
      {
         "==":[
            {
               "var":"matchStatus"
            },
            true
         ]
      }
   ]
}

Custom true/false condition (Professional or Enterprise only)

Configure a true/false condition based on specific business rules that you determine in JSON format.

For example, you can use this condition to check whether a custom checkbox field has been selected for a tag dimension.

In this case, this condition returns:

  • True: The JSON-specified condition is met.

  • False: The JSON-specified condition is not met.

✏️ Note
While the Custom true/false may appear similar to the True/false condition, it can “drill down” on objects that are present on the invoice.

The True/false condition checks data that is indicated on the invoice (such as a custom field, value, etc.), while the Custom true/false is able to is able to pull other data. For example, it can check the cost object that the invoice is assigned to and check the logic.

You can build complex business rules and serialize them as JSON. The JSON rules are specified in the Rules field of the node options.

❗️Warning
Currently you can only perform this “drill down” for cost objects.

Check that custom field is flagged on cost object

You can set a rule to check if on the cost object, the custom information checkbox is equal to true (i.e. selected). If so, it returns true.

  1. Identify the custom field in the company on the tag. The label field value (CustomFieldLabel) MUST be specified in the expression below.

  2. Add a true/false node and copy and paste this snippet into the Rules field:
    ​

    {
      "some": [
        {
          "var": "_costObjects"
        },
        {
          "==": [
            {
              "var": "customInformation.<CustomFieldLabel>"
            },
            true
          ]
        }
      ]
    }

  3. Set up the workflow in the legal entity.

Check that custom field is not present/present on a PO header

You can set up a rule to check on the PO if the custom information is null or has a certain value. This example checks if the PO does NOT contain any custom information in the PO’s header.

🚧 Caution

Make sure your integration sends the PO with custom fields.

To do this, you need to check the payload being sent to Yokoy, as Yokoy does not display custom PO information in the PO.

Add a custom true/false node and copy and paste this snippet into the Rules field:

{
    "some":
    [
        {
            "var": "_purchaseOrders"
        },
        {
            "==":
            [
                {
                    "var": "customInformation.<nameOfTheField>"
                },
                null
            ]
        }
    ]
}

Check that custom field is not present/present on a PO line item

You can set up a rule to check on the PO if the custom information is null or has a certain value. In this example, it checks if the PO does NOT contain any custom information in the PO’s line items.

🚧 Caution

Make sure your integration sends the PO with custom fields.

To do this, you need to check the payload being sent to Yokoy, as Yokoy does not display custom PO information in the PO.

Add a custom true/false node and copy and paste this snippet into the Rules field:

{
    "some":
    [
        {
            "var": "_purchaseOrders"
        },
        {
            "some":
            [
                {
                    "var": "items"
                },
                {
                    "==":
                    [
                        {
                            "var": "customInformation.<nameOfTheLabel>"
                        },
                        null
                    ]
                }
            ]
        }
    ]
}

✏️ Note

If you have multiple matched invoice line items, some with custom information and others without any custom information, the condition node returns true as at least one of the items has the condition verified.

Check that the matched PO line item requires a GR or not

The purchase order determines whether a goods receipt is required and should be used in three-way matching. You can check to see whether a corresponding GR line item is required. 


   "some":[
      {
         "var":"_purchaseOrders"
      },
      {
         "some":[
            {
               "var":"items"
            },
            {
               "==":[
                  {
                     "var":"requireGoodsReceipt"
                  },
                  true
               ]
            }
         ]
      }
   ]
}

Check if current approvers are not submitters of the invoice (4-eye principle check)

You can set a rule to check if on the invoice, the approvers who are selected for approval are part of the submitter list.

  • If none of the selected approvers are listed as a submitter of the invoice, it returns true

  • If at least one person has both submitted and is the approver of the invoice, it returns false

{
  "and": [
    { "!": { "in": [ { "var": "currentApproverIds.0" }, { "var": "submitters" } ] } },
    { "!": { "in": [ { "var": "currentApproverIds.1" }, { "var": "submitters" } ] } },
    { "!": { "in": [ { "var": "currentApproverIds.2" }, { "var": "submitters" } ] } },
    { "!": { "in": [ { "var": "currentApproverIds.3" }, { "var": "submitters" } ] } },
    { "!": { "in": [ { "var": "currentApproverIds.4" }, { "var": "submitters" } ] } },
    { "!": { "in": [ { "var": "currentApproverIds.5" }, { "var": "submitters" } ] } },
    { "!": { "in": [ { "var": "currentApproverIds.6" }, { "var": "submitters" } ] } },
    { "!": { "in": [ { "var": "currentApproverIds.7" }, { "var": "submitters" } ] } },
    { "!": { "in": [ { "var": "currentApproverIds.8" }, { "var": "submitters" } ] } },
    { "!": { "in": [ { "var": "currentApproverIds.9" }, { "var": "submitters" } ] } }
  ]
}

🚧 Caution

Only the first 10 entries of the array currentApproverIds are checked against the submitter list. If necessary, add additional objects within the “and”:[…] array of the JSON logic.

Contains no overspent line items

Set up a true/false condition to determine whether the invoice has been overspent. In this case, the condition returns:

  • True: If there is no overspending on the invoice i.e. no invoice line items have an overspent status, it returns true.

  • False: If there is overspending on the line items of the invoice, the condition returns false.

❗️Warning
This condition cannot be used before an approval node. If the next node is an approval node, it blocks the workflow.

✏️ Note

The overspent status is triggered if an invoice is outside the range that is set in the purchase order matching tolerances.
​

Supplier with property (Enterprise only)

Configure a true/false condition based on a specific field or fields. You can compare any supplier values. For example:

  • Supplier name (supplier.name)

  • Supplier ERP code

  • Supplier payment terms

  • Supplier custom information

In this case, this condition returns:

  • True: The property specified matches the supplier attribute on the supplier - which is found on the invoice

  • False: The property specified does NOT match the attribute specified on the supplier found on the invoice

To set up this node, you enter the data field to be checked and the value(s) contained in that field:

Option

Type

Description

Field

String

Data field of the supplier.

For example, if you want to use a custom field, the value is customInformation.<CustomFieldName>.

You can put here any supplier data field you want, such as the supplier name, payment terms.

Matches

String or number

Value to check in the field specified.
You can enter multiple values by clicking + Add row.

If you want to use a boolean value, make sure to enter it all lowercase true or false.

✏️ Note
Click Apply to save the field and matches values. Otherwise, all changes are lost.

For example, if you want to perform a specific action for a specific group of suppliers, you can specify the field as supplier.name and the Matches value with several supplier names, such as Acme, MyCompany, etc.

The condition returns “true”, as it compares the information on the invoice with the information present on the supplier.

Submission to own cost center

Set up a condition that returns true/false if the invoice’s cost object is the same as the submitter’s cost object. In this case, this condition returns:

  • True: The invoice is coded with cost objects whose owner is the same person who submitted the invoice.

  • False: The owner of the cost objects derived from the invoice is not the same as the submitter user.

The condition returns true if any of the submitters present on the invoice is equal to the cost object owner of the invoice cost object.

For example, if an invoice with two line items is submitted by “Alex 1”:

  1. Line item 1 with cost object owner “Alex 1”

  2. Line item 2 with cost object owner “Yokoy support”

The condition returns true and moves the invoice to the next step, even if there is a different cost object owner for one of the line items.

✏️ Note

Yokoy checks the full list of submitters selected on the invoice document.

Contains matching alert (Enterprise only)

Configure a true/false condition to determine whether any matching alerts have been triggered for the document. In this case, this condition returns:

  • True: If there are any matching errors on the invoice, it returns true.

  • False: If there are no matching errors on the invoice, it returns false.

For example, You can use this node where if there is a missing goods receipt and you try to submit the invoice, Yokoy detects this state and the condition node returns true. The step after this node depends on the specific scenario.

Currently, the list of notifications Yokoy can check are as follows:

Alert

Scenario

supplierInvoiceNotification.lineItemBlockedGr.title

Checks if the goods receipt item that has been matched is blocked or not. Goods receipts (like POs) can be blocked; meaning that they should not be used further for processing. Yokoy flags that case and this condition node allows you to check for that.

supplierInvoiceNotification.lineMissingGr.title

Checks if the purchase order is missing a goods receipt. This is usually used to signal that a purchase order is still waiting from a confirmation of delivery, i.e. a goods receipt (but the goods receipt has not yet been posted).

supplierInvoiceNotification.lineItemPoBlocked.title

Checks if the matched PO line item has the status Blocked. This is usually used when you don’t want to further proceed with the workflow if the PO is blocked from the ERP. Blocked means that no more budget should be allocated to the item.

supplierInvoiceNotification.lineItemBPoCancelled.title

Checks if the matched PO line item has the status Cancelled. This is usually used when you don’t want to further proceed with the workflow if the PO is cancelled from the ERP.

Non-PO line items present (Professional or Enterprise only)

This node allows you to check if any of the line items on the invoice has the Non PO matching status. If so, it then returns true. Otherwise, it returns false.

It is typically used to design workflows where you need to check if you have additional costs that have not been included in the purchase order. If so, you may require additional approval from the cost object owners.

Check if additional unplanned costs that are not present on the PO need to be approved

Purchase orders (POs) are for companies a way to control spend and budget. While POs capture most of the spend, sometimes additional costs may need to be recorded outside of the PO scope. For example, additional freight or shipping costs that were not included when the PO budget was initially approved.

To cover this use case, you can use the Non PO line items present condition node, which checks if there are additional costs in the invoice document that were not included originally in the PO. Most companies require additional approvals if this is the case. Hence, you may want to set up the following configuration:

  • If non-PO line items are present, perform additional approval (e.g. a cost object approval)

  • If non-PO line items are not present, do not perform additional approval (e.g. go directly to In review status)

Typically, you chain this condition node with a PO invoice condition node, as it is often the case that non-PO invoices are treated differently.

Submitter with property (Professional or Enterprise only)

This node allows you to configure a condition node that returns true/false if the invoice’s submitter group contains a specific property. You can check any user property such as name, email, line manager, as well as custom fields.

This node can only be used by customers with a Professional or Enterprise plan.

In this case, this condition returns:

  • True: The cost object associated with the submitter’s invoice has a specific property value.

  • False: The cost object associated with the submitter’s invoice does not have the specific property value.

For example, if the condition is set up with the Line manager property and matches Alex Smith,

  • If a submitted invoice is created by a user whose line manager is “Alex Smith“, it returns true.

  • If a submitted invoice is created by a user whose line manager is “Devis Hirt“, it returns false.

Option

Accepted values

Description

Property

String

Name (ID) of the field to be checked on the cost object. For example, it can be any fields present on the cost object, from the cost object name to a custom field.

Matches

String / Number / Boolean

Value of the cost object property to be checked.

To add multiple values, click + Add row.

Setting up submitter property validation on a custom field

For example, if you want to check if the user in the custom field Target Administration has value “G000" or "G001":

  1. You have a custom field set up in the user profile:

Name

Label

Type

customInformation.targetAdministration

TargetAdminstration

Text input

  1. Click the Submitter with property node in the Workflow Designer and enter this data. Since you want to check multiple values, enter the value “G001” and then click + Add row to add the second value “G002“:

Option

Value

Field

customInformation.targetAdministration

Matches

G001 G002

The result is as follows:

In this case, Yokoy checks if the submitter has this property. If true, it performs a cost object approval. If false, it moves the document to “In review”.

Invoice age ≤ max. threshold (Professional or Enterprise)

This node allows you to check the age of an invoice and ensure it doesn’t exceed a maximum threshold. If the invoice exceeds the maximum set, then it returns a false. It is typically used to design workflows where you need to check if an invoice date is not older than a certain number of days.

The node performs the following calculations:

  • Checks the Invoice date on the invoice.

  • Computes the difference between today’s date and the invoice/payment date on the invoice.

  • Compares with the value entered in the node’s configuration (max. age in days).

  • Returns:

    • if the difference > max. age: false

    • if the difference < max. age: true

For example, companies often want to prevent users from submitting invoices that are older than a month or two. With this node, it is possible to define a specific workflow path that if the invoice is older, it cannot be submitted.

Option

Accepted value

Description

Max. age in days

Numeric

This fields allows to specify the maximum amount of days after which the invoice is considered to not meet the condition.

Only numeric numbers are allowed (e.g. 1, 2, 3, 30, etc.)

Three-way matching discrepancies present (Professional or Enterprise)

This node allows you to configure a true/false condition to determine whether any matching alerts have been triggered for the document in the context of three-way matching and route the invoice document accordingly. For example, you can use this node to check if there are any three-way-matching discrepancies detected such as quantity mismatch, amount mismatch or missing goods receipt.

In this case, this condition returns:

  • True:

    • If there are any matching errors on the invoice, as configured by the user in the node option.

  • False:

    • If there are no matching errors on the invoice, as configured by the user in the node option.

You can select one or several of these three cases, depending on your preferred configuration setup. For example, place the condition after Submit to check if the invoice has or not some three-way matching-related discrepancies. If that is the case, you may decide to inform the user via Assign workflow notification and route the document to Needs Revision.

Invoice activity nodes

Invoice activity nodes perform a specific action on the document in the workflow.

You can perform these actions in the workflow:

✏️ Note

Before the activity node, you need a status node (New, Draft, Needs revision).

After the activity node, you can add any other workflow node type (status, activity, condition or approval nodes).

Assign approvers with property (Enterprise only)

Determine approvers based on a specific property users have in their user data.

It can be used to create approval groups or to dynamically assign users based on specific custom properties that can be set on the user profile.

In this case, this condition returns:

  • True: it requires an approver with the options specified in the action. If the approver is not present, it does not move forward.

  • False: it requires an approver with the options specified in the action. If the approver is not present, it does move forward.

For example, you can this workflow node to assign as approvers all users with the property customInformation.TeamA equal to true. This means that all the users with the checkbox Team A ticked on their profile are assigned for approval.
​
This specific condition comes with two options that must be completed:

Option

Accepted values

Description

Property

String

User property data field.

For example:

  • User first name: firstName

  • User last name: lastName

  • User email: email

  • User ERP code: employeeId

  • Custom field: customInformation.<customFieldName>

Value

String / Number / Boolean

Value of the attribute in Yokoy.

For example:

  • user.name: Alex

  • user.lastName: Smith

  • user.email: alex.smith@example.com

  • user.employeeId: 1234

  • customInformation.[labelName]:

    • if a text input field: a string such as manufacturing or G004

    • if a checkbox: true / false

Assign all cost object approvers

Assign all the cost object owners as approvers. Technically, it iterates through the various line items of the invoice, extracts the cost object owners, and assign them for approval.

For example, you configure Yokoy to assign all cost object owners and require approval from all owners when an invoice is submitted.

🚧 Caution

It must be used in combination with Cost object approval to create a cost object flow.

In this case, this condition returns:

  • True: If Yokoy cannot find an approver, it keeps the document in the same status.

  • False: If Yokoy cannot find an approver, it moves the document to the next status.

🚧 Caution

If you have delegates with an expiry delegation date in the past, they are not included in the assignment for approval. These delegates are ignored as their expiration date has past.

Assign custom cost object approvers (Enterprise only)

Determines cost object owners as approvers based on a specific property. Technically, it iterates through the various cost centres on the invoice, and assign approvers based on the properties specified in the options.

🚧 Caution

It must be used in combination with Final approval node.

This specific condition comes with options that must be completed:

Option

Accepted values

Description

Cost object field

String

The field on the cost object to be looked up.

User field

String

User property on the cost object.

Required approvers

true / false

  • True: Determines that at least one approver must be defined for the cost object. If no approvers are defined, the invoice does NOT move to the next step.

  • False: Does not require an approver for the cost object.

Transformations

lowercase

If you want Yokoy to ignore case for the user field, select this checkbox.
When selected, if you write “USER.COMPANY@COMPANY.com”, Yokoy can parse this as “user.company@company.com”.

For example, you want to assign a special user (which is not the cost object owner) for approval using the cost object on the invoice:

  1. Add a custom field thirdApprover to the cost object.

  2. Reference the cost object field (in this case, the custom field custom.Information.thirdApprover) and the corresponding user value where you'll find the mail to identify that user (in the standard user.email field).

  3. In this case, you can specify any user mail you want on the cost object, and Yokoy assigns that user. So the submitter codes the cost object in the invoice. From that cost object, Yokoy picks the user specified with that mail address.

✏️ Note
This field is not case sensitive. If you write “USER.COMPANY@COMPANY.com”, Yokoy can parse this as “user.company@company.com” using the Transformations field.

✏️ Note - Custom information fields
Custom fields can only be set up by Yokoy. You may need to open a support ticket if the custom field you require doesn‘t already exist in your Yokoy implementation or if you don’t know the name (which may or may not be the same as the label shown in the app).

Assign all cost object line managers (Enterprise only)

Assign the line managers of all the cost object owners as approvers. It checks the cost object value and assigns the line manager of the cost object owner who respects these conditions. If no dynamic escalation is provided, it assigns the line manager of the CO owner, in general (without checking).

For example, you configure Yokoy to assign the line managers of all cost object owners and require approval from all owners when an invoice is submitted.

🚧 Caution

It must be used in combination with Cost object approval to create a cost object flow.

In this case, this condition returns:

  • True: If Yokoy cannot find an approver, it keeps the document in the same status.

  • False: If Yokoy cannot find an approver, it moves the document to the next status.

Option

Type

Description

Field

String

Approval group field where you have set up dynamic escalation.
For example, customInformation.subgroup where you have set up an approval group.

Operator

>, >=, <, <=

  • Greater than (>)

  • Greater than or equal to (>=)

  • Less than (<)

  • Less than or equal to (<=)

Value

String or number

Value to check in the field specified.
You can enter multiple values by clicking + Add row.

Require approvers

true / false

  • True: Determines that at least one approver must be defined for the cost object. If an approver is defined and this checkbox is selected, the invoice does NOT move to the next step.

  • False: Doesn't require an approver for the cost object.

Assign all tag approvers

Assign all tag approvers with a given tag value found on the invoice document as approvers. Technically, it iterates through the various line items of the invoice, extracts the tag values approvers and assign them for approval.

The node comes with two options:

Option

Accepted value

Description

Require approvers

true / false

  • True: Determines that at least one approver must be defined for the tag. If not, the flow is stopped.

  • False: Doesn’t require the tag to have an approver. If this is the case, it proceeds with the next step in the flow.

Tag dimension ID

String

Tag dimension to be used.

You can specify one or multiple tag dimensions to be considered by Yokoy. You can add as many dimensions as you want. For example, you can set up two tag dimensions on the invoice: one for approval and one for coding. You can also set up Yokoy to consider just the one you want.

If you leave the tag dimension ID empty, by default Yokoy considers all dimensions on the document.

🚧 Caution

Tag dimension IDs are specific for each environment and organization.

💡 Tip

You can look up the tag dimension ID for the legal entity in Admin > Company, Enable tags section. If you click on the tag dimension, the ID appears at the bottom of the form.

There are two options when configuring tag workflows regarding IDs:

  • Do not enter any tag dimension ID in the workflow: The workflow considers all tag dimensions on the invoice document. This means that the workflow could be reused across environments, without amendments.

  • Enter tag dimensions IDs in the workflow: The workflow considers only that tag dimension. This means that you would need to create first a workflow entering the TEST tag dimensions ID and another workflow with the PROD tag dimension IDs.

Assign custom tag approvers (Enterprise only)

Determine cost object owners as approvers based on a specific property. Technically, it iterates through the tag values on the invoice, and assign approvers based on the properties specified in the options.

🚧 Caution

It must be used in combination with Final approval or All approvers must approve nodes.

Option

Accepted values

Description

Code (ERP)

String

Code of the Tag dimension.

Tag value ERP code

String

This is the tag custom field. It should be something like:

customInformation.<tagValue>

User field

String

The user field to look up to match what has been entered in the tag field. If you want to assign the mail, the value should always be email.

Require approvers

true / false

  • True: Determines that at least one approver must be defined for the cost object. If no approvers are defined, the invoice does NOT move to the next step.

  • False: Does not require an approver for the cost object.

For example, if you want to assign a special user (which is not the cost object owner) for approval using the cost object on the invoice:

  1. Add a custom field additionalApprover to the tag.

  2. Reference the Tag dimension ERP code field and the Tag field (in this case, the custom field customInformation.additionalApprover) and the corresponding user value where you'll find the mail to identify that user (in the standard email field).

  3. In this case, you can specify any user mail you want on the cost object, and Yokoy assigns that user. So the submitter codes the cost object in the invoice. From that cost object, Yokoy picks the user specified with that mail address.

✏️ Note

This field is not case sensitive. If you write “USER.COMPANY@COMPANY.com”, Yokoy can parse this as “user.company@company.com” using the Transformations field.

✏️ Note - Custom information fields
Custom fields can only be set up by Yokoy. You may need to open a support ticket if the custom field you require doesn‘t already exist in your Yokoy implementation or if you don’t know the name (which may or may not be the same as the label shown in the app).

Assign static approver (Enterprise only)

Assign an approver by a specific ID. In short, it assigns a specific user for approval for the legal entity. It is often used to assign a final user for approval if certain conditions are met, such as for invoices greater than 50K, assign the CEO.

This node comes with options that must be completed:

Option

Accepted values

Description

Static approver ID

String

User ID of the user to be used for this special approval.

You can add multiple users by clicking + Add row.

Require approvers

true / false

  • True: Determines that at least one approver must be defined. If none are found, then Yokoy stops the flow.

  • False: Doesn’t require an approver to be defined. If this is the case, it moves to the next step in the flow.

For example, you can set up this node to assign two users as approvers and link it with a Final approval node. Any of these users can approve and end the approval flow.

Assign default supplier approver

Assigns the approver set up by default on the supplier as the approver. For example, you set up the workflow to assign the approver set up on the supplier as the approver.

Option

Accepted values

Description

Require approvers

true / false

  • True: determines that at least one approver must be assigned in the supplier profile. If none are set, then Yokoy stops the document in the flow.

  • False: doesn’t require an approver in the supplier profile. If Yokoy cannot find an approver, it moves the document to the next step in the flow.

Assign line manager

Set up a workflow where all line manager of the user who either submitter or last approved are assigned as approvers. It must be used in combination with Line manager or escalate.

This node has two options:

Option

Accepted values

Description

Line manager of

Submitter / Last approver

Last approver: Yokoy takes the line manager of the last person who approved.

Submitter: Yokoy takes the line manager of the person who submitted the invoice document.

Require approvers

true / false

  • True: Determines that the user who submitted the document must have a line manager. If not, the document remains stuck before submission.

  • False: If the user does not have a line manager, Yokoy skips this step and goes to the next step in the flow.

Assign SAP document approvers (Enterprise only)

Set up an assigner, assigning users from the custom field of the cost object as approvers. This is a special node that is only valid for SAP invoice customers who need to replicate their approval tables in Yokoy by using cost objects.

🚧 Caution
The cost center must have a certain key format of the custom information - customInformation.approvers. If this information is not present it WILL NOT work.

❗️Warning
You must not select delegates in Yokoy when you use this approval flow. Customers using the SAP approval flow must set delegates in SAP, which are then automatically sent to Yokoy.

This node has with two options that must be completed:

Option

Accepted values

Description

Object

cost center

Cost Center. This is the object where Yokoy fetches the JSON schema of the approvers.

Currently, only Cost Centers are supported.

User key

String

Data field on the user where Yokoy receives the SAP user ID. This field is required for this node to work.

For example, customInformation.SAPuserID

For example, you can set up a workflow where Yokoy assigns as approvers the users that are fetched from the cost center custom information by pointing to the SAP ID specified on the user key (in this case, customInformation.SAPUserId).

Trigger an error (Enterprise only)

Set up Yokoy to send an error message when a certain action/condition occurs.

Unlike Assign workflow notification, this activity node stops the workflow completely and does not add any additional log to the document itself.

This node has one option:

Option

Accepted values

Node

Error message text

String

This is the error message you want to specify and return to the user. It is a text message that is displayed as a result of the action.

For example, you can set up a flow where in the case of overspending, Yokoy sends a message “Please revert to procurement”.

Workflow notification (Enterprise only)

Set up Yokoy to send an informative message when certain action/condition occurs.

Unlike Throw an error, this activity node just sends information to the user, so that they can acknowledge it and move onto the next step.

The node has two options:

Option

Accepted values

Description

Notification text

String

This is the text you want to send to the user when the action occurs.

Notification type

Info / Warning / Error

Type of notification sent to the user. Depending on how important the information is, the user see an information message, a warning or an error.

For example, you can set up a notification to be triggered in the event there is overspending to send an information message to users that says “Note that there is an overspending!”

Assign PO owner as approver

This node assigns the owner that is set up on the Purchase Order as the approver. The PO owner is specified

💡Tip
Use this node set up a supplier approval flow in combination with Final approval.

Option

Accepted values

Description

Require approvers

true / false

  • true: Determines that at least one approver must be assigned in the Purchase order. If none are set, then Yokoy stops the document in the flow.

  • false: This means that an approver is not required in the Purchase Order. If Yokoy cannot find an approver, it moves the document to the next step in the flow.

For example, you set up the workflow to assign the approver set up on the Purchase Order as the approver.

Invoice approval nodes

Invoice approval nodes complement activity nodes in the workflow to perform specific invoice business logic.

✏️ Note

Before an approval node, you need an activity node.

After an approval node, you need Need revision, Draft, Reject, and In review status nodes.

You can use these approval nodes:

All approvers must approve (Enterprise only)

Set up an approval flow that forces all approvers assigned by the activity node to approve the document.

Technically, what this node does is the following:

  • Once a tag approver approves, it removes the approver ID from the list of current approver IDs

  • Assigns the document to other approvers assigned to the invoice document still need to approve.

Once all approvers have approved the document, it moves the document to the next step in the flow.

Use cases

You can use this node with these nodes:

Final approval

Set up a couple of multiple approval flows, depending on what you need.

Technically, what this node does is when multiple approvers are assigned to a document, when a user approves the document, it clears the list of remaining approvers assigned, and moves the document to the next step in the workflow.

Use cases

You can use this node with these nodes:

Cost object approval

Lets you set up a cost object approval flow. Technically, what it does is the following:

  • It deals with the escalation to the parent cost centre, if needed

  • Completes the first activity node Assign all cost object approvers

This specific node has several options:

Option

Accepted values

Description

Escalate to parent cost object

true / false

Determines whether there are escalations to parent cost objects, once the approval thresholds are met.

Use net amount

true / false

Tells Yokoy to use net amounts of the document, and not gross amounts (by default). For example, invoice 1500 CHF gross, 1200CHF net.

If you tick this option, Yokoy compares the net amount with the approval threshold of the cost object.

Check for independence

true / false

Yokoy extracts the submitter from the event log, and whenever the submitter equals the approver for an approving cost center, Yokoy tries to escalate to the parents of all cost centers that are being approved.

The Check for independence checkbox is used to determine in cases where the submitter is the same as a cost object approver, approval is escalated to the owner of the parent cost object to meet compliance.

Use cases

You can use this node with these nodes:

Line manager approval or escalate

Set up a line manager workflow with the Assign line manager. Technically, it deals with escalation to the line manager hierarchy when a certain user approves sequentially.

Use cases

You can use this node with this node:

SAP approval (Enterprise only)

Set up a special approval flow in combination with Assign SAP document approvers. Technically, this node handles the business logic to extracts custom information from a cost object and assigns it to the various approvers.

This is a special node that is only valid for SAP invoice customers who need to replicate their approval tables in Yokoy by using cost objects.

🚧 Caution
The cost center must have a certain key format of the custom information. - customInformation.approvers. If this is not present it WILL NOT work.

❗️Warning
You must not select delegates in Yokoy when you use this approval flow. Customers using the SAP approval flow must set delegates in SAP, which are then automatically sent to Yokoy.

This node has with two options that must be completed:

Option

Accepted values

Description

Object

cost center

Cost Center. This is the object where Yokoy fetches the JSON schema of the approvers.

Currently, only Cost Centers are supported.

User key

String

Data field on the user where Yokoy receives the SAP user ID. This field is required for this node to work.

For example, customInformation.SAPuserID

Use case

You an use this node with this node:

Did this answer your question?