Lately, I have spent some time assessing the invoice approval workflow capabilities in standard Dynamics AX 2012 R2. There is a number of ISV solutions in the market claiming to enhance the standard experience. Therefore, I decided to throw a common scenario at the standard workflow to see how it coped. Wether the ISV solutions do a better job is not for me to say, so in the following I only commented on the standard functionality available.
TWO TYPES OF INVOICE
In my assessment, I have used two different types of invoices namely:
- Stock purchasing
- Non-stock purchasing
In my experience, stock purchase invoices mainly relate to products bought for the sole purpose of reselling them or consuming them as part of a value-add (manufacturing) process. Most of the companies I have worked for have a two or three-way matching policy for these invoices, but this task is mainly carried out in the Accounts Payable (AP) department without involving the purchaser. If the AP user is unable to match the invoice, the invoice is sent for approval to the purchaser. In this case, we would need a workflow, which allows the AP clerk to submit the invoice for approval by the purchaser marked on the purchase order.
Non-stock purchasing, in my experience, can come in two flavours: firstly, we have invoices for services, stationary, consumables etc. ordered by someone in the business without issuing a purchase order. Other businesses have a policy enforcing the use of purchase requisitions and purchase orders. In the latter case, it is easy to track the person, who ordered the goods or services. In the first case, we need to be able to submit the invoice for approval by a specific person or by the head of the department most likely to have placed the order. In the second case, we should be able to ascertain the ownership from the purchase order meta-data.
In all the above cases, we need a two-stage approval process. Firstly, the person, who made the order must review the receipt and vouch for the receipt and correctness of the received goods or services. Once the invoice has been reviewed, it must be escalated to the reviewer’s manager for budget approval.
INVOICE REGISTER AND APPROVAL JOURNAL
Albeit Microsoft has introduced approval workflows for the invoice register and the invoice approval journal, I cannot see many businesses using these workflows in real life. These workflows enable the approval of an entire journal without any real ability to view the invoice image or the purchase order matching. This to me seems like a workflow only applicable to very small businesses, who probably would not automate the invoice approval process in the first place. I would expect these journal types to disappear in future releases…
In my scenario, we have a manufacturing company (Contoso Entertainment System USA). The company uses purchase orders for stock purchases and purchase requisitions for non-stock purchasing. Contoso applies a purchase order approval workflow and three-way matching of stock invoices, so if an invoice can be matched, there is no need for further approval. All non-stock invoices must go through explicit approval. Non-stock invoices are approved by the head of department.
The company receives invoices as a mix of e-mails (PDF), electronic (XML, OIOUBL) and paper.
VENDOR INVOICE POLICIES
Firstly, I configure the vendor invoice policy rules. The vendor invoice policy rules allow you to apply queries to the invoice during approval and posting. This is not applicable to my scenario, but could be used, if you need to filter certain invoices from the normal approval process. An applicable scenario for this could be shared service centres.
Subsequently, I need to set up the matching policy. By default a general matching policy is set up for the entire company. However, this policy can be overwritten by item or vendor or a combination thereof. In my scenario, I elect to set up matching policy by vendor because my vendors do not supply both stock and non-stock items.
[UPDATE 4/7/2013] As George Chernev kindly pointed out on LinkedIn, it is also possible to set up matching policy on the procurement category (using category rules in purchasing policies).
Anyway, in my scenario, the stock vendors are set up for three-way matching and non-stock vendors are set up for two-way matching.
Subsequently, I set up my matching tolerances. I can elect to match by line or by total. Since I am using two and three-way matching, it makes sense to apply tolerances by line. You can also set up tolerances for the charges. In my scenario, I am using charges matching since transport is a significant landed cost component in Contoso. I have also set the system up to require approval for invoices that cannot be matched.
THE APPROVAL WORKFLOW
Now I need to establish how the approval workflow should work. The workflow template provides two levels in the approval process namely review and approval. In my scenario, I am not using the review process, but for some companies, it may be applicable to have a two-stage review-approval. However, it is not possible to assign an invoice for review by the person, who placed the purchase order, and to me that seems a bit strange. However, by being a bit creative, it is possible to assign an invoice for review (by a queue or expenditure reviewer), if the invoice does not match the purchase order.
As the following figure shows, I am setting up an approval workflow, that automatically posts the invoice once all lines have been approved.
As the above figure shows, the invoice policies are evaluated as the first step. Then a work item is assigned for all the invoices lines.
Now we come to probably the most interesting question: how do we set up the invoice approval assignee?
Dynamics AX provides four approval assignee types namely:
- Workflow user
When assigning the workflow item to a User, you must select a single user, which in most companies is not relevant when it comes to invoice approval. Assigning the invoice to a Workflow user (workflow owner or workflow originator) does not seem relevant either. The workflow owner is static and recorded in the workflow properties whereas the workflow originator, in this case, will be the AP user invoking the workflow. Neither of those are relevant for our scenario.
Obviously, using an organisational hierarchy (see Microsoft Technet for more information on hierarchies) seems ideal for our scenario. With a hierarchy, the workflow will escalate the approval work item until it meets the conditions set for assignment. In this scenario we would set the condition to assign the work item when it encounters a person in the hierarchy with an approval limit higher than the value of the invoice. So far so good, but there is a catch: the hierarchy traversal must start somewhere and you have the choice of either workflow owner or workflow originator.
Again, workflow owner does not make any sense. Assuming that a centralised AP department is taking care of invoice registration, workflow originator does not make any sense either because the workflow originator can not be part of every sub node in the organisational hierarchy.
In reality, the organisational hierarchy is useless in terms of the invoice approval workflow.
This brings us to the participant type; in this case the participant is called the Vendor Invoice Expenditure Reviewer (VIER). You can read more about configuring VIER here. You can set up VIER to be assigned based on either the financial dimensions or project attributes (project manager, project controller and sales manager) or a combination thereof. When assigning the work item based on the financial dimensions, the workflow engine will look at the owner of the financial dimensions. This is likely to work in most instances, but in an organisation where the departmental manager has delegated the invoice approval task, it seems a bit one-dimensional (no pun intended) to me. Once the assignee has been determined, the workflow engine must determine whether the employee has an appropriate signing limit (see section Signing Limits below).
Based on my findings, the only work item assignment scheme that works in reality is based on VIER.
This may be adequate in some organisations and scenarios, but I would clearly have expected the workflow to work with the organisational hierarchy out-of-the-box. Also, I would have expected the traversal of the organisational hierarchy to take its starting point in meta-data provided from the purchase order because essentially this is the source document.
Signing limits for invoices in Dynamics AX 2012 R2 are based on job definitions (or salary level). Basically, the signing limit is linked to the power of attorney implicit in the job function. The signing limit is set up in a policy framework. The policy framework appears prepared for leveraging the organisational hierarchies, but I have so far only been able to set up policies by company. This is probably fine for many organisations, but it would be useful if the signing limits could be configured by business unit, department etc. The benefit of this approach is, that if a user changes job role, the power of attorney automatically changes. The drawback is, that to make full use of the signing limits, you have to implement significant chunks of the HRM module.
For more information on signing limits, please see Microsoft Technet.
MULTIPLE APPROVAL ASSIGNEES
In the workflow item assignment you are able to define whether a single, all, the majority or a percentage of approval assignees must approve the work item before the status is finally changed to approved. To me, this seems awkward because normally power of attorney is singular. If you want multiple approval assignees, you are probably better off introducing multiple review steps. Anyway, the feature is there, if you need it.
ESCALATING OVERDUE ITEMS
On the workflow item you can set a time limit for task completion. When you set an escalation path for overdue items you are able to assign the overdue item to a new user with a new time limit. However, if the escalation path does not result in an approval, you must define whether the workflow engine should automatically approve or reject the item.
One of the very strong features of the workflow engine is the ability to automate tasks. Many companies have a threshold below which invoices are automatically approved, if they match the purchase order. This can be automated using conditions in the workflow.
RECORDING AN INVOICE
To leverage the invoice approval (or invoice line approval) workflow, the invoice must be recorded using the Open invoices or Pending invoices screens. When the recording starts, the user can start the registration from a blank record or use an existing purchase order or product receipt to base the registration on.
I will not venture too deeply into the recording process in this blog post, but suffice to say, that I believe this registration screen is a vast improvement on the invoice register used in previous versions. The matching and policy violation displays are very useful.
The above screenshot shows an example of the invoice matching screen with a discrepancy clearly highlighted (red exclamation mark).
APPROVING AN INVOICE
Now that the work item has been assigned to the correct user, it is time to approve or reject the invoice. The approval task works like any other work item using the workflow engine. The obvious starting point for invoice approval is the role centre. In the role centre it is possible to preview the work item, but this does not show the invoice image (attached using the standard attachments feature). As the following screenshot shows, the user can go to the open invoice screen and display the attached invoice image:
It is clearly a disadvantage that the user must use the rich client to display the invoice image. If users are happy to use the rich client instead of the role centre (using the Work items assigned to me screen), the system works quite nicely.
One of the main benefits of using the invoice register in previous versions of Dynamics AX was the ability to account for incoming VAT as soon as the invoice was recorded. This ability is lost when using the open / pending invoice screens. However, it is possible to report on open invoices and make a manual accrual or you can use the goods-received-not-invoiced (GRNI) accrual from the stock module to calculate the incoming VAT, but this does not necessarily include non-stock purchasing.
[UPDATE 4/7/2013] In some of my previous projects there has been a need to reassign the invoice to different accounts and financial dimensions after it has been recorded (essentially what the invoice regster / approval journal currently does). This is a common scenario when a shared service centre scans / records the invoice and then sends it out to a local AP user in the department / business unit etc. The workflow does not specifically have this step built in, but by assigning a review work item to a queue based on invoice meta-data, you should be able to provide a workable solution. Please note, that the AP user will need to access the rich client to change the accounting distribution.
SEGREGATION OF DUTY
In many organisations the person, who raised the purchase order is not allowed to approve the invoice due to the company’s segregation of duty policies. Since the workflow engine does not currently provide meta-data from the purchase order in the assignment are, it is not possible to provide this segregation of duty. You can obviously work around this problem in a number ways, but it is not ideal.
Dynamics AX 2012 R2 provides a simple AIF service for importing supplier invoices. However, the service does not allow for import of image attachments as standard, so you must expect some tweaking before the service is useable in real life.
In the above brief walk-through of the invoice approval workflow in Dynamics AX 2012 R2, I have tried to concentrate on some real life issues. It is clear to me that Microsoft has taken a step forward from previous versions by providing a useable invoice approval workflow. The invoice approval workflow CLEARLY works best in combination with a strict policy for purchase requisition / purchase order approval to allow for deficiencies in the work item assignment functionality.
However, in its current incarnation, the functionality relies too heavily on default workflow behaviour and does not allow for the real-life scenarios relating to invoice approval in many mid-size and larger companies. This is a shame because the fundamentals of the workflow engine work well. So here is hoping that future releases will address these issues. In the meantime, it is probably worth taking a look a the ISV solutions available – as long as they leverage the standard policies framework and workflow engine.
WANT TO KNOW MORE?
You can read more about accounts payable workflows on Microsoft Technet.
You can also read about configuring vendor invoice management here.