This guide covers purchase invoice automation and its use in Netvisor. With purchase invoice automation, you can, among other things, define purchase invoices as factually verified, approved, or set to payment prohibition directly using conditions. Automation functions can also be used, for example, to post purchase invoices or allocate them to purchase orders according to company-defined rules. Purchase invoice automation can be managed in the section Purchases>Purchase invoices>Automatic processing. 

CONTENTS

With automation, you can, among other things, define a purchase invoice as factually verified and/or approved directly. Also, posting and setting cost objects can be done using functions and desired conditions. With automation, you can also, among other things, define invoices to payment prohibition using desired conditions. If the company has the purchase order section in use, for example, a purchase invoice can be posted and allocated to a purchase order using automation. 

Access to the view requires the Purchase invoice automation rules right from the purchase and accounts receivable rights of the company in question. Additionally, there must be at least edit rights to the purchase receivables views and lists. 

Automation is activated by pressing the button automation off, which then turns green and reads automation on. Automation processing does not work if the invoice is zero-sum or a credit note. 

The processing history of purchase invoice automation is retained for 13 months. Older history entries will be deleted. Entries made by automation in the purchase invoice history will remain for the duration of the invoice's existence.


Common rules

Common rules are automation processing rules that apply to all vendors' purchase invoices. If necessary, rules can also be made vendor-specific. Before starting use and activating the service, it is worth considering the option that better suits your purpose. A common rule is easier to manage if the same function fits the same conditions for multiple vendors. Rules open from the downward arrow, showing the rule description and validity period. If the rule is expired, it appears as an orange "dot". This also results in a notification on the homepage exceptions and notices widget "expired purchase invoice automation rules". The notification can be cleared by extending the rule's validity period or deleting the expired rule. 

Rule order

The order of rules can be changed by pressing the left mouse button on the rule row and moving it under the desired row. The rule number appears in front of the rule row, and rules are always checked from the smallest number onwards. For example, it is worth considering making exceptions first and general rules lower with a larger number. The rule always goes by number order, even if the vendor has a defined rule, it is only considered based on its system number. If the row has a sequence number of -, the row is not run for the selected vendor. 

If the function in the rule has already been done by a previous rule, the subsequent rule does not perform/override the same function. For example, it does not change the bookkeeping account or cost objects.  The view allows general rules to be run first, then vendor-specific, and finally common rules. These are processed based on the sequence number. 

Rule editing, deletion, and events

A rule can be edited by opening the desired rule from the downward arrow button and pressing the edit button. From this view, you can also access vendor linking and define the rule for desired vendors. 

A rule can be deleted by going to rule editing and pressing delete rule. The events button shows rule edits and, for example, the reason why the rule did not work for the desired invoice. For example, in the rule below, the invoice channel did not match, and therefore the invoice was not processed using the rule. Events can be searched by date and, for example, by invoice.

New common rule

Creating a new rule begins by giving the rule a name and optionally a description. 

The validity period must be set from which date the rule is valid. If no end date is set, the rule is valid indefinitely. If the invoice already exists in the system, the automation rule does not process it, even if the validity period is set to a date in the past.

 

Functions

At least one rule must be created for functions. If multiple functions are created, the rule can be deleted from the button at the end of the row. When creating functions, it is worth considering the order, i.e., if the same function target has already been set earlier. An example of this is a posting rule that does not work if posting has already been set by a higher-level rule. Or if too many functions are created with the same rule, not all are fulfilled, and some remain undone.

Conditions: From here, select the condition when the rule is run. 

Invoice processing

Set circulation list: From here, you can select an existing invoice automation circulation. Managing circulation lists requires the 'Purchase invoice approval circulation setter' right from the receivables rights. Detailed instructions for approval circulation can be found on its own help page here. Circulation lists can also be used to build an exceptional approval circulation for substitution. In this case, the created rule must be given the desired validity period during which this rule is valid. This helps speed up invoice processing time, as desired invoices can be directly approved. An example is administrative invoices, such as rent and internet connection invoices, which recur at regular intervals. The automation rule overrides the possible company default circulation list. 

Set invoice to payment prohibition: With this, the invoice goes to payment prohibition and cannot be paid without removing the prohibition. This is recommended, for example, in situations where it can be assumed that many invoices or goods will come from vendors that need to be manually checked.

Automatically record rounding difference: If there are cent deviations on the invoice, these can be directly recorded to rounding differences on the purchase invoice posting rows. This saves posting working time. The transaction appears on the purchase invoice posting row, and then it can be posted either manually or using an automation rule that posts the invoice.

Set booking date: The rule allows setting the booking date to the month before or after the invoice date. 
This rule allows easily directing desired invoices to be automatically booked either to the month before or after the invoice date. This function should be set to invoice processing before the invoice posting function. If posting is done by automation, a separate rule must be made after this rule. The program does not move the invoice to a locked period with this condition but gives the invoice an error message in the processing history. The booking date is in a locked period. Also, if there are other conditions in the same rule, they are not run.

Post invoice: Automatically posts the invoice. Posting occurs based on the invoice default posting option. If the invoice is not factually verified with the same rule, this makes a preliminary posting for the invoice. Posting becomes visible when the invoice is factually verified and posted.

Approval: You can choose whether the invoice goes directly to factually verified, approved, or rejected. The rule cannot be run multiple times in succession, so if you want the invoice approved, you must make a direct rule that approves it and cannot have a separate factual verification rule before this. 

Suspend automation and move to manual processing: With this option, automation is not used, and the invoices of the rule must be completely manually processed. This is good, for example, when the first invoice comes from a new vendor, so the vendor and the correctness of the invoice sent by them can be checked before taking it into the automation scope.

Accrue invoice: With this, an accrual can be automatically made for the entire purchase invoice. From the list, select the existing accrual rule you want to use. 

Automatically save posting suggestions: If there is a posting suggestion obtained by AI on the row, you can choose which percentage probability over the suggestion is saved to the purchase invoice row. The rule also works in the same rule for the function that posts the invoice. 

Processing all invoice rows

Set bookkeeping accounts for all invoice rows: This selects the desired bookkeeping account as default for the purchase invoice. The account must be active in the specification of accounts.

Set cost objects for all invoice rows: With this, the desired existing cost object can be made visible on the purchase invoice posting row. Detailed instructions on cost objects can be found on its own help page here. You can select only one cost object under one cost object heading, but you can select multiple cost objects if they are under different headings. With cost objects, you can see the postings on target accounting reports and track, for example, location transactions.

Post invoice rows based on a model invoice: This option is convenient for recurring, such as administrative invoices. The first field selects the model invoice, showing the invoice number and vendor name. The model invoice must have come as an e-invoice to the company to be selectable from the list. The model invoice must not be posted once, or otherwise, automation does not work in the background. This rule does not create a voucher for the invoice but brings the posting rows retrieved according to the rule to the purchase invoice posting rows. If you also want to create a voucher, we recommend making an automation rule after this rule that posts the invoice. The visibility of the voucher also requires that the invoice must be at least factually verified, or otherwise, it remains in the preliminary posting status. 

The second field has a choice of whether VATs, bookkeeping accounts, and cost objects are also set based on the model invoice. If necessary, you can choose from the options below.

The last field defines the basis on which the model invoice information is combined with posting, i.e., whether the product code, product name, and/or either of these are used. Additionally, it is possible to use row specification in allocation. If using the product code, name, or row specification, these must be on the example invoice and the new incoming invoice for the program to allocate them together. If, for example, the product code is empty, no allocation is made. 


Here, if necessary, multiple model invoices can be used, but the products first in the rule are posted first, and with subsequent conditions, those products not found on the previous model invoice are posted. This way, model invoices can be chained to the rule if there is a need to compare products from multiple invoices. However, it should be noted that if a posting row corresponding to the product has already been processed based on a previous rule, additional rules do not change the posting of this product row. So, attention should be paid to the order of rules. If only part of the rows from the invoice match the posting rule model invoice/invoices, those rows are processed. Rows that do not match the rule are left unposted, and nothing is done to them.

Set row specification for all invoice rows: With this, the row specification on the purchase invoice posting row can be defined by automation or override the specification that came with the e-invoice. Here, the option is to give the specification as the product name, code, or own specification. If you choose your own specification and leave it empty, no separate row specification will be successfully processed for the purchase invoice with this rule. The row specification field on the purchase invoice will be empty, but when the invoice is posted and at least factually verified, the voucher will have the row specification as the vendor name, invoice, and then the invoice number. The rule should be run before the possible invoice posting rule.

Processing selected invoice rows

All selected invoice row processing events must be done in automation rules before the invoice posting rule. The posting rule must then be a separate rule after these rules.

Accrue invoice rows: Selected purchase invoice rows can be accrued with the desired accrual rule. The condition for accrual can be row specification, product code, or product name. The rule can be run in the same rule with the posting rule or can be run on an already posted invoice. 

Allocate invoice rows: Desired invoice rows can be allocated with an existing allocation rule. The condition for allocation can be row specification, product code, or product name. The allocation rule can be run in the same rule with the posting rule or can be run on an already posted invoice. 

Partial VAT deduction (%): The VAT-free portion of the invoice row sum can be selected. The condition can be specification, product code, or product name, which is the desired value, or starts, ends, or contains the desired value. The rule can be run in the same rule as the invoice posting or can be run on an already posted invoice. 

Set VAT for invoice rows: With this, you can enter the desired same values either for all rows or only individual rows based on specification, product name, or product code. The rule can also be run only for the desired VAT code row or only for the desired VAT % row. The rule can be run in the same rule with the posting rule or can be run on an already posted invoice. 

Set bookkeeping account for selected invoice rows: With this function, the desired bookkeeping account can be given only to one purchase invoice posting row. The rule can be limited to apply to all rows or can be selected that the row must have a certain specification, product code, or product name for this function to be used. Specification, product code, and name can also be limited so that it must match completely, or the beginning must be a certain value, the end a certain value, or this contains a given word. The limitation can also be made so that the VAT code must be a certain one, or the VAT percentage must be a certain one. 


Set cost object for invoice row: With this function, the desired cost object can be given either to all rows or only to the row with a certain name, product code, or product name. This can also be limited based on VAT code or VAT percentage. 

Vendor

Set vendor to payment prohibition: The vendor of the rule can be set to payment prohibition. It can be used for example, when creating a new vendor, when you want to ensure the correctness of the vendor. Payment prohibition prevents the payment of all vendor invoices.

Credit note processing

Set invoice to payment prohibition: This function can set payment prohibition for invoices, which only affects the payment of credit notes. If this is done, credit notes cannot be paid to the bank if the rule condition matches. 

Invoice and purchase order allocation

Mark as related to purchase invoice: This feature requires the purchase order section to be enabled in the company. This is needed first in the rule pipeline if row-specific functions are to be done for the purchase invoice and purchase order. Allocation can be done between different vendors if necessary, so attention should be paid to the condition field and define it precisely enough. If the purchase order is in the proposal or archived status, the purchase invoice cannot be allocated to the purchase order using automation. 

Invoice and purchase order row allocation

This feature requires the purchase order section to be enabled in the company.

Link purchase invoice rows to purchase order: You can choose whether the rule automatically links purchase invoice rows to the purchase order. The status of the linked purchase order must be approved or sent for the link to occur. If no specific conditions are selected, the link occurs by default according to the product code + product name. The function links purchase invoice rows to purchase order rows if:

-There are a maximum of 20 times more linkable purchase order rows than purchase invoice rows.

-The total sum of the allocated purchase order rows is at most twice as large as the sum of the allocated purchase invoice rows.

-The purchase invoice is allocated to a maximum of five different purchase orders.
Link purchase invoice rows to purchase order considering backorder: This rule works like the link purchase invoice rows to purchase order rule. In this rule, it is worth using the condition Purchase invoice row sums differ from purchase order row sums at most (%) considering backorder selection or Purchase invoice row quantities differ from purchase order row quantities at most (%) considering backorder selection. 

Copy posting information from purchase order to purchase invoice rows: You can choose whether to copy the bookkeeping accounts and/or only possible cost objects from the purchase order to the purchase invoice. (Postings can be prepared on purchase order rows during the order creation phase). For allocation to be done, the purchase order and purchase invoice must have exactly the same product. The product code or product name must match completely. If it does not match, allocation is not done, even if the conditions otherwise match.

Copy unit prices from purchase invoice to purchase order rows. This updates the correct purchase prices from invoice rows to purchase order rows and also to stock management.

Conditions

At least one condition must be selected. Here, it is defined under which condition(s) the created automatic processing is performed.

Invoice meets given conditions

Invoice sum: Define the invoice sum range. The invoice must be within this sum range to be processed with the created rule. Multiple sum ranges can be given if necessary.

Our reference/Your reference: Define that the our reference/your reference field must have certain text for the rule to be valid. Or our reference starts or ends with the desired text or contains the desired text.

The first set value from these fields is read into the Your reference field, in this order:

 "/Finvoice/DeliveryDetails/WaybillIdentifier"

 "/Finvoice/InvoiceDetails/OrderIdentifier" 

"/Finvoice/InvoiceDetails/BuyerReferenceIdentifier"

The value set in the SellerReferenceIdentifier field is read into the Our reference field.

Reference number/message: This allows defining whether the reference/message must match completely for the rule to be valid or whether the desired beginning or ending is sufficient. It can also be defined that the reference/message must contain the desired numbers/letters.

Contract identifier: Use contract identifier information as the condition for performing the function. The value set in the AgreementIdentifier field is read into the Contract identifier field.

Vendor's bank account (IBAN): Enter the vendor's bank account in IBAN format, which must match for the rule to be valid. Multiple accounts can be selected, and it is sufficient that one of these matches.

Recurrence: It can be defined how many weeks the rule repeats. The starting field must be given a date. Define how often the invoice repeats and from when the rule is desired to be valid. It should be noted here that even if the rule's start is set in the past, the rule is not used for already received invoices. The rule only works for invoices coming after the rule's creation. It is good to set the expected invoice date in the starting date, as the rule's recurrence tracking is based on it. There is a few days tolerance in recurrence. So, if there is a monthly recurring invoice, the invoice date can deviate by +-3 days. If there is a deviation in recurrence, even a week, then it is no longer recognized, and the rule does not work because of this. If the invoice is processed with the recurrence condition, the same automation rule does not process another invoice during the same period. So, for example, a monthly recurring rule can process a maximum of one invoice per month.

Invoice source: E-invoice, scanning service, or manual. That is, through which channel the invoices processed with this automation rule came. If necessary, invoices from multiple channels can be selected. Purchase invoice automation takes the invoice for processing if it is an e-invoice or if the scanned invoice vendor is identified "strongly", i.e., at least by name and business id. E-invoice information is considered more reliable than scanned invoice, so the automation condition is stricter for scanned invoices. For e-invoices, identification by business id alone is sufficient.

Invoice with the same number found from vendor: Choose whether an invoice with the same number must be found from the vendor for the rule to work. You can also choose the option no.

The sum of the invoice and invoice rows differs (€): Define the difference range within which the function is performed. For example, you want to record rounding differences to purchase invoice posting rows for deviations under five cents, then enter values 0-0.05 in the fields.

String found in the e-invoice message header field: This can be used to search for information up to 70 characters long from the purchase invoice finvoice message. Information is searched from the message before the invoice row fields. The solution is not case-sensitive, so, for example, the word Lappeenranta on the message is also searched with the search condition lappeenranta. The search condition, e.g., PL 55, is treated as one search condition if it is on one line in the condition. The condition must match completely, not just the word PL. Conditions can be searched from multiple places on the message by entering multiple words in the condition field.

If using multiple condition rows, it is sufficient that one of these matches. For example, if the first row contains PL 55 and the second row contains the word Lappeenranta. It is sufficient that Lappeenranta is somewhere on the message before the invoice row information. 

String found on the e-invoice message row: This can be used to search for characters and numbers from the invoice invoicerow rows. The maximum number of characters that can be searched is 70. The solution is not case-sensitive, so, for example, the word Lappeenranta on the product row on the message is also searched with the search condition lappeenranta. The search condition, e.g., PL 55, is treated as one search condition if it is on one line in the condition. The condition must match completely, not just the word PL. Conditions can be searched from multiple places on the product rows on the message by entering multiple words in the condition field. 

Invoice rows meet given conditions

Invoice row product code: A condition can be given that the product code must match completely or start/end or contain the desired characters for the rule to be valid. The visibility of the product code requires an e-invoice or purchase order allocation to the purchase invoice, where information is retrieved from the purchase order.

Invoice row product name: A condition can be given that the product name must match completely or start/end or contain the desired characters for the rule to be valid. The visibility of the product code requires an e-invoice or purchase order allocation to the purchase invoice, where information is retrieved from the purchase order.

Invoice row specification: A condition can be given that the specification must match completely or start/end or contain the desired text for the rule to be valid.

Invoice row cost object: A condition can be defined where the invoice row cost object must match the cost object given in the condition.

Invoice vendor meets given conditions

Vendor created with invoice: A condition can be defined where it is considered whether the rule works if the vendor is created with the invoice. That is, if the vendor is, for example, automatically created and these invoices are wanted, for example, for manual verification, select yes for created.

Invoice bank account meets given conditions

Bank account created with invoice. A condition can be defined where it is considered if a new bank account is created with the arrival of the invoice. The condition is valid until the bank account is confirmed. Bank account confirmation can be done from the invoice or behind the vendor from bank account management, and both ways confirm the bank account.  With this, an automation rule can be made where the invoice goes to payment prohibition based on the rule when a new bank account arrives, so the correctness of the new account can be more closely checked. 

A corresponding purchase order is found for the invoice with header-level conditions

Purchase order is in status: It can be defined what the status of the purchase order must be for automation to consider it. The selection is approved or sent to vendors.

Delivery status: Define what the delivery status must be for the condition to be fulfilled. The options are undelivered, partially delivered, delivered, and over-delivered.

Combine purchase order: A condition can be defined when the purchase order is allocated to the purchase invoice. The options for combining are that the purchase order number matches the invoice your reference information, the purchase order number is marked as belonging to the invoice, or our purchase order reference matches the invoice your reference information. 

Purchase order sum differs from purchase invoice sum at most (%): It can be defined how much the sum can differ in percentage for automation processing to work. Purchase orders require the purchase order section to be used in the company.

Purchase orders found (pcs): It can be defined the range of how many purchase orders must be for the rule to work.

A corresponding purchase order is found for the invoice with row-level conditions

Allocate purchase order rows to purchase invoice rows: A condition can be chosen whether the purchase order is combined with the purchase invoice if the purchase order product code, name, and/or product name and code match. The purchase order must be approved and sent/printed. 

Correspondence found for purchase invoice rows from purchase order: A condition can be chosen from the options All purchase invoice rows have corresponding purchase order rows, all purchase order rows have corresponding purchase invoice rows, and lastly, some purchase invoice rows have corresponding purchase order rows.

Purchase invoice row sums differ from purchase order row sums at most (%): It can be defined the maximum percentage value that the purchase order and purchase invoice can differ from each other for the purchase order and purchase invoice to be linked together. Here, taxable final sums are compared. The purchase order shows the sum field as a tax-free sum, but the purchase order rows show the taxable sum, which must fall within the desired percentage limit value. This should be used with the function Link purchase invoice rows to purchase order. The function links purchase invoice rows to purchase order rows if:

  • Linkable purchase order rows are a maximum of 20 times more than purchase invoice rows
  • The total sum of the allocated purchase order rows is at most twice as large as the sum of the allocated purchase invoice rows
  • The purchase invoice is allocated to a maximum of five different purchase orders

Row allocation occurs by default according to the product code + product name. If this is to be changed, the rule must include allocate purchase order rows to purchase invoice rows, and then the allocation method can be changed as follows.

Purchase invoice row sums differ from purchase order row sums at most (%) considering backorder. This works like the above condition but also considers backorder. This should be used with the function Link purchase invoice rows to purchase order considering backorder. Here, taxable final sums are compared. The purchase order shows the sum field as a tax-free sum, but the purchase order rows show the taxable sum, which must fall within the desired percentage limit value. This should be used with the function Link purchase invoice rows to purchase order. The function links purchase invoice rows to purchase order rows if:

  • Linkable purchase order rows are a maximum of 20 times more than purchase invoice rows
  • The total sum of the allocated purchase order rows is at most twice as large as the sum of the allocated purchase invoice rows
  • The purchase invoice is allocated to a maximum of five different purchase orders

Row allocation occurs by default according to the product code + product name. If this is to be changed, the rule must include allocate purchase order rows to purchase invoice rows, and then the allocation method can be changed as follows.


Purchase invoice row quantities differ from purchase order row quantities at most (%): It can be defined the maximum percentage value of the product quantities of purchase invoice and purchase order rows that can differ. If the difference is within the percentage value, the purchase order and purchase invoice are allocated together. This should be used with the function Link purchase invoice rows to purchase order. 

Purchase invoice row quantities differ from purchase order row quantities at most (%) considering backorder. Works like the above condition but considers backorder. That is, the product quantities of purchase invoice and purchase order rows are compared. This should be used with the function Link purchase invoice rows to purchase order considering backorder.

Purchase order rows have quality deviations: If the company has quality handling in use for purchase orders, it can be defined in the conditions whether there can be quality deviations on the purchase order for allocation to occur. For example, allocation can be prevented if not all purchase order products are of prime quality.

After going through the selections for all functions and conditions, the save button must be pressed. If necessary, a row can be deleted from the button at the end of the row. If a row remains red when pressing the save button, it means that the information for that row is missing. They must either be added or the entire row deleted.

After the save button, the selection is made where the vendors linked to the rule can be chosen. In the selection, either selected vendors or the company's entire vendor register can be chosen. After this, the view must still be saved.

If you choose selected vendors. This option is recommended for rules that involve purchase invoice approval functions. This ensures that no misuse occurs for new vendors.

NOTE! If automation rules are not fulfilled, the rule is bypassed in invoice processing. The invoice then remains in the system as a new invoice and must be manually processed. The Events log for the vendor-specific rule will then show that the purchase invoice automation conditions have not been met.

Vendor-specific rules

Common and vendor-specific rules can be used simultaneously. The first box contains common, the middle vendor-specific, and the bottom box again common rules. Rules are processed based on the rule sequence number, i.e., number 1 always first, even if it is in general rules and there is rule number 2 behind the vendor.

To select a vendor-specific rule, the desired vendor must first be selected from the vendor listing. 

After this, the desired rule can be created for the vendor from the new vendor-specific rule button. This opens a similar view as the general rules, the selections are the same as presented above. The difference is that the vendor-specific rule is only valid for the specific vendor. The general rule is valid for all vendors. 

 

Summary

The view shows invoices received for the desired period, how many invoices have been processed using created automation rules, and possibly exceptions that occurred in automation.

Suggestions for automation rules

Suggestions may appear in this view from an invoice received from a vendor, from which an automation rule could be formed. If information appears visible here, you can drill down into the rule view that is suggested. If necessary, conditions and functions can still be edited for the rule at this point.

Events

From the history, you can see which invoices have been processed by automation and which invoices have possibly moved to manual processing when conditions have not been met. Invoice-specific information can also be found on the purchase invoice.

Best Practices

General notes and best practices in creating rules

  1. Vendor-specific rule or rule for multiple vendors? -> A common rule is easier to manage if the same function fits the same conditions for multiple vendors. 
  2. Common and vendor-specific rules can be used simultaneously. The first box contains common, the middle vendor-specific, and the bottom box again common rules. Rules are processed based on the sequence number, which appears before the rule name.
  3. When should common vendor rules be first and when last? 
  4. Rule prioritization, i.e., automation order, is done in the management view using the “drag&drop” method, i.e., dragging the rule to the desired place.
  5. General rules should be placed lower in prioritization, and exceptions to them higher, so they are done. If the function in the rule has already been done by a previous rule, the subsequent rule does not perform/override the same function. For example, it does not change the bookkeeping account or cost objects.
  6. Row-specific functions are completed by the next rule if conditions are met and the invoice row has not been allocated the function in the rule (e.g., posting from a model invoice, multiple model invoices can be selected for the rule, and rules are retrieved row-specifically depending on which of these rules “hits”). 
  7. It is advisable to make 1 rule per function + conditions, as no function is done in the rule if even one condition is not met. In this case, the condition intended for another function blocks all other functions in the rule (copying is still missing, so it is worth investing in common rules = reducing micromanagement). 
  8. A function always requires at least one condition selected from the conditions menu to work (=3rd menu on the rule). The condition must also be selected in a situation where the function box contains the selection of conditions related to the function.
  9. If making common rules, do you want the entire vendor register or only selected vendors?
    1. Entire vendor register = also vendors added after the rule creation use the rule
    2. Selected vendors = All vendors can be selected at the time of rule creation, but vendors added to the vendor register after this do not use the rule unless they are added from the rule card (this option is smart to use when the rule involves functions related to payment automation or approval, so that a new vendor invoice created over the interface or upon arrival of the purchase invoice is not taken through the approval or payment pipeline before the correctness of the vendor is verified. This ensures that no misuse occurs.

Example functions: Invoice processing at a high level

Setting approval circulation = vendor circulation list bypass

With this function, the desired invoice circulation list can be selected using automation. That is, the desired factual verifier and approver defined in the circulation list can be obtained for invoices. In the example below, the circulation list "Desired circulation list for the company" has been selected, and the conditions are e-invoices, scanning service, and manual invoices, i.e., all new invoices. If necessary, conditions can be changed, for example, to use a certain invoice sum range as a condition.

Every time you press the save button after the rule, you come to the vendor selection. From there, you can choose selected vendors and select the desired vendors to whom the rule is set or all vendors.

Selected vendors: This option is recommended for rules that involve purchase invoice approval functions. This ensures that no misuse occurs for new vendors.

Entire vendor register: Note that more vendors added to the vendor register after rule creation also use the rule.

Setting an exceptional approval circulation for substitution (validity period)

Now the circulation list has also been given a validity period. This way, a circulation list can be made, for example, for substitutions, which is valid until a certain date. When the validity period expires, the rule is no longer valid. In the example below, the validity period expires on 29.9.2017, so after that, the rule no longer works automatically.

Setting payment prohibition for invoice (important function if it can be assumed that many invoices or goods will come from vendors that need to be manually checked.) In the example below, the invoice is set to payment prohibition, and the condition is all invoices over 100 €. Of course, the condition can be something else.

Invoice approval: Factual verification, approval, rejection

With this function, the invoice can be automatically defined as factually verified, directly approved, or directly rejected if necessary. A suitable condition must be given, under which the invoice is directly marked as approved.

Suspending automation and dropping to manual processing (this is good, for example, when the first invoice comes from a new vendor, so the vendor and the correctness of the invoice sent by them can be checked before taking it into the automation scope). In this case, automation does not do anything to this invoice.

Automatically recording rounding differences in cent deviations for the invoice and invoice rows

Below is an example where the rounding difference of the invoice and invoice rows is automatically recorded. The condition used is the difference between the invoice and invoice row sums. In the example, a maximum difference of 10 cents is used, but this can be defined as the desired difference, allowing automation to record rounding differences. Recording the rounding difference does not change the invoice sum. A rounding difference entry row appears on the purchase invoice posting rows, and then the invoice can be posted either manually or using an automation rule that posts the invoice.

In the example below, the invoice would be posted if the invoice row product code contains only the example code 1234. The condition should be considered suitable for oneself, and if necessary, if you want to automate the posting of invoices containing certain product codes or names, you can select multiple of these for the condition.

 Invoice row processing

Setting the same bookkeeping account for all invoice rows at once. With the rule, an active bookkeeping account can be set as default on the invoice posting row with the desired condition. Below is an example of setting account 4000. If there are no automatic postings in the rules, the account can still be changed manually during manual posting. The condition should be considered suitable for the company.

Setting multiple cost objects for all invoice rows at once

With this, the desired existing cost object can be made visible on the purchase invoice posting row. Detailed instructions on cost objects can be found on its own help page here. You can select only one cost object under one cost object heading, but you can select multiple cost objects if they are under different headings. With cost objects, you can see the postings on target accounting reports and track, for example, location transactions.

A suitable condition must be selected for the company, e.g., a cost center set based on the invoice row product or name.

This article has been translated using an AI-based translation tool. The contents or wording of these instructions may differ from those in other instructions or in the software.



Did you find it helpful? Yes No

Send feedback
Sorry we couldn't be helpful. Help us improve this article with your feedback.