The previous webcasts illustrated how one can make use of electronic reporting and MS Flow to create accruals for vendor invoices recorded through the pending vendor invoice form. Within this webcast I will extend this approach and show how electronic reporting can be used for automatically retrieving and posting accruals with the financial dimension values that have been entered with the originating vendor invoice.
This webcast extends the previous one and shows you how you can incorporate a signing limit approval Matrix in MS-Flow that is used for approving vendor invoices from D365FO. In addition, you can see how invoice meta data from MSDyn365FO can be sycnronized with SharePoint in order to allow users finding posted invoices quickly and easily.
This post continues my previous one and shows you how you can combine D365FO and MS-Flow workflows to send out and process MS Flow approval emails that allow the users responding to an approval request directly in the Email and view the invoice document as an email attachment.
A general problem when recording and paying vendor invoices is the question how to ensure that invoices are not entered and paid more than once. What sounds like common sense can involve a lot of practical problems especially when it comes to recording and paying expense related vendor invoices that are not linked and tracked through purchase orders.
Imagine the following scenario where an employee orders some advertising material (brochures) for the next trade fair. As the total order value is quite small and given that the costs for the brochures are going to be expensed directly, the advertising material is ordered straightaway via Email without making use of the purchase requisition / purchase order process.
If the vendor sends a copy of the invoice together with the shipped advertising material and the original invoice via Email, an invoice – and copies thereof – arrives several times in a company.
For the sake of this demonstration let’s further assume that the invoice copy is forwarded from the warehouse agent to the employee who ordered the goods. After checking and approving the invoice it is then forwarded to the Accounts Payable department where it is recorded by an AP clerk for the first time in the ERP system with invoice no. “INV1234”.
Let’s continue the scenario by assuming that the original invoice is sent to the Accounts Payable department where another AP clerk forwards the invoice to the marketing manager for approval. If the marketing manager does not coordinate with his employee who placed the order, the invoice might get approved and recorded a second time in the system e.g. with invoice no. “INV 1234”. Please note that this time the invoice is recorded with a blank before the number and as a result, the invoice is not identified as a duplicate invoice by the ERP system, as the invoice numbers “INV1234” and “INV 1234” differ from a technical perspective.
At this point three questions arise:
- How to identify that an invoice has been recorded more than once in the system?
- How to avoid paying the vendor twice? and
- How to avoid double entries of invoices altogether?
Within the following subsections I will try answering those questions by referring to Dynamics AX standard features.
Q1: How to identify that an invoice has been recorded more than once in the system?
In order to answer the first question, I will slightly modify the scenario portrayed in the beginning of this post. To understand and follow up the example, it has to be noted that the AP parameter “reject duplicate” invoices is activated. Please see the next screen-print.
Next, two invoices are recorded in a vendor invoice journal. The first invoice is entered with invoice number “INV1234” and the second one with invoice number “INV 1234”. That is, the second invoice is recorded with a blank between the term “INV” and the invoice number. Because of that blank, Dynamics AX treats both invoices as distinct records.
Referring back to our scenario introduced above – and different from the illustration in the previous screen-print – the first and the second invoice would have been entered by different AP clerks in different vendor invoice journals. Because of a (“human”) typing error, Dynamics AX cannot identify that the same invoice has been entered twice.
Now let’s extend the scenario by recording another two invoices with invoice numbers “INV.1234” and “INV1234.” in the vendor invoice workbench. That is the invoices are entered with a dot in between respectively behind the invoice number. Please see the next screen-print.
Due to the blank and dot characters used, the invoice was finally recorded four times in Dynamics AX. This can be identified from the vendor invoice journal form illustrated next.
After entering those four invoices we will now try identifying the duplicate invoices by making use of the audit policy feature available in the audit workbench module. (In AX2012 the same functionality can be found in the compliance and internal controls module).
The first thing that needs to be setup in this module is a policy rule type that makes use of a predefined query (“vendor invoice”) that is incorporated into standard Dynamics AX. The query type used is “duplicate” as we want to search for invoices that have been entered more than once. (Additional information on the available query types can be found on the following TechNet site).
Next, an audit policy needs to be setup and linked to an organization. Please see the next screen-print for an example.
The last and most important setup required is the specification of an audit policy rule that identifies the duplicate invoices. Example:
The criteria that the audit policy rule uses to identify (potentially) duplicate invoices are entered in the “group by” filter tab. In my example, I specified that invoices with the same amount and date for the same invoice account are potentially duplicate invoices.
Please note that the invoice number cannot be used as a criteria, as all the invoice numbers that we entered differ.
Once the audit policy rule is established, a batch job needs to be setup which analyzes all vendor invoices for potentially duplicate records based on the criteria that we specified before.
If the invoice batch search process finds duplicate records, it creates a case where it lists the potentially duplicate invoices as illustrated in the next screen-print.
Note: A prerequisite not explicitly mentioned/illustrated here is the setup of an audit type case category in the organization administration module. Details for this setup can be found on the following TechNet site.
If you take a close look at the duplicate vendor invoices identified above, you will notice that Dynamics AX only listed the invoice numbers with the dot characters in the audit case window. On the other hand, the invoices that were entered in the vendor invoice journal are not picked up and identified as duplicates.
The underlying reason for this standard behavior is the Dynamics AX policy framework. That is, only those invoices that do – among others – have a source document header and source document line associated are picked up by the audit policy check. As the invoices recorded through vendor invoice journals do not have this association they are not taken into consideration by the audit policy rule.
This standard behavior of the audit policy rules does have three major implications:
- If you want to make use of the audit policy rule functionality, vendor invoices cannot be recorded through vendor invoice journals.
- Alternatively, a comprehensive system modification needs to be implemented, and
- Given that users are still allowed entering invoices through vendor invoice journals, manual checks for duplicate vendor invoices are required to avoid double payments.
From the authors perspective the first implication that requires entering all vendor invoices through the vendor invoice workbench seems to be superior as it provides one single point of entry for vendor invoices irrespective of whether those invoices are linked to a purchase order or not.
What is more, recording expense related invoices by referring to descriptive categories rather than a multi-digit ledger accounts reduces the risk of typing/posting error especially if temporary employees or trainees are recording vendor invoices in the system. Example:
Please note that users still have the chance to overwrite the ledger account that is linked to the category if necessary, as illustrated in the previous screen-print.
Even if users are familiar and used to entering vendor invoices through the Dynamics AX vendor invoice journals, a process change towards entering all invoices through the vendor invoice workbench might be beneficial. That is not only because of the audit policy functionality mentioned before but also because of the standard Excel-import and workflow processes that can be associated with the invoice workbench resulting in an overall streamlined and simplified invoice recording process.
Q2: How to avoid paying the vendor invoice twice?
Based on what has been said before, you can setup and process an audit policy rule for duplicate vendor invoices before you start making vendor payments to minimize the risk of making double payments. As mentioned previously, this requires that all invoices are entered through the vendor invoice workbench. Otherwise your only option is executing manual checks for potentially duplicate invoices that might require a lot of time and resources.
Q3: How to avoid double entries of invoices altogether?
The audit policy process introduced in this post helps you identifying whether an invoice has been entered more than once. That is, the feature is able to identify with hindsight that something went wrong that needs to be cured.
As prevention is usually better than cure, the question arises how one can prevent similar scenarios as the one described in the introduction of this post?
From the author’s perspective the best and safest way for avoiding duplicate vendor invoice records is a complete and consistent use of the Dynamics AX purchase order process for each and every purchase that is made in your company. This requires that also expense related and often small value purchases are processed through purchase orders. Especially for small- and medium-sized companies this might sound like taking a sledgehammer to crack a nut. However, I made the experience that especially small- and medium-sized companies are the ones that do not have the most stringent organizational business processes in place and as a result are the most likely ones running into the risk of entering and paying invoices double.
I hope you enjoyed reading this post and would be happy if you could share your experience with the AX community on how to prevent duplicate vendor invoices & payments in Standard Dynamics AX. Thank’s and till next time.
Within this blog post I will describe the newly released Accounts Payable invoice group and invoice payment group functionalities.
Let’s start by having a look at the invoice group feature. The new invoice group feature can be made available by activating the following Accounts Payable parameter:
After this parameter is activated, users can decide whether the default invoice group code is based on (a) user name, (b) date or (c) “custom”.
A result of this setup is that a new “invoice group” field can be identified in the vendor invoice form. This newly available field is initialized with the default invoice group code that has been setup; in my case with my user ID “$1D58”.
After posting the vendor invoice, the invoice group entered can be identified in the invoice journal form.
Based on this additional information various analyzes can be performed such as e.g. the number of invoices entered per day or the number of invoices entered per employee, etc. The outcome of those investigations can thus be used for the setup of an activity based cost management.
Irrespective of those advantages, a couple of disadvantages remain.
- The first disadvantage is that the invoice group field is currently not available in the various Accounts Payable invoice journals such as e.g. the invoice journal, the invoice approval journal, etc.
- A second disadvantage is that the default invoice group values can be changed to any other combination consisting of numbers and characters. As an example, the user ID “XYZ” that is shown in the previous screenshot does not represent a valid user ID in my demo company.
- A final disadvantage is that invoice groups cannot be used for summary updates of receipt lists, packing slips and vendor invoices.
Invoice payment groups
The second newly created “invoice payment group” feature is a Dynamics AX public sector functionality that becomes available with the activation of the corresponding license code in the system administration module. It can be made available by activating the following Account Payable parameter (please see the next screenshot).
As for invoice groups, the activation of the invoice payment group parameter makes a new field available in the vendor invoice form.
When a vendor payment proposal is created later on, the invoice payment group code can be used for filtering on invoices with the same payment group code. As an example, a filter for urgently to pay invoices can be setup.
If – for example due to a payment date filter setting – one or more invoices that belong to the same invoice payment group are excluded from the payment proposal, a warning message with the following text pops up:
From the warning message illustrated in the previous screenshot you can identify that the invoice payment group feature helps users verifying whether all invoices that belong to the same invoice payment group – e.g. those that need to be paid urgently – get paid.
Despite this advantage, the currently available invoice payment group functionality has also some disadvantages: First, invoice payment groups are limited to a single vendor, which prevents an immediate use of this feature in practice. Second, as mentioned before, the vendor payment group functionality is a Public sector feature that requires some code adjustment to get rid of some unnecessary info/error Messages in private company system environments.
In summary, the use of invoice groups and invoice payment groups offer some new and interesting possibilities for finance & controlling users. Yet, because of the several issues mentioned before, both features cannot be applied directly in a live environment without making some system modifications.