The Invoice Approval Workflow


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.


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.


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.


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.


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:

  • User
  • Workflow user
  • Hierarchy
  • Participant

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.


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.


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.


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).


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.


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.


You can read more about accounts payable workflows on Microsoft Technet.

You can also read about configuring vendor invoice management here.


About Henrik Marx Larsen

I have worked with Microsoft Dynamics AX / 365 for Finance and Operations since 1997. I started out as a developer and progressed through multiple roles to become a Principal Architect. I have worked in a number of industries including manufacturing, distribution, professional services and retail. I am passionate about Microsoft technologies and ERP in particular. All views shared on this blog are mine alone and do not necessarily reflect the views of my employer.
This entry was posted in Accounts Payable, AIF, Dynamics AX, Procurement, Role Centres, Workflows. Bookmark the permalink.

14 Responses to The Invoice Approval Workflow

  1. Pingback: Happy Holidays | henrikmarx

  2. Pingback: ISV AP Automation Solutions | henrikmarx

  3. Claus says:


    The article gives a very good overview of the possibilities and limitations in connection with the workflow and it is nice to get a better understanding of which workflows to use.
    I completely agree with you that the solution is going in the right direction, but there is some strange limitations.
    Will it be possible for you to export your examples and send them to me, to be able to understand how you have setup the workflows. I know that they will not work without setting up other stuff in the system, but I hope in can clarify the validation rules.
    I think you are missing handling of invoices not related to a purchase. All companies will have this kind of invoices, even they have a policy to use purchase orders. If I understand it right should you use a different screen to handles these invoices.
    I also think it is important to address the license cost because, many users will approve invoices and I guess that they need a task user to be able to approve an invoice.

  4. henrikmarx says:

    Claus, first of all many thanks for your comments. As discussed on the phone, I was a bit lazy in my post by not fully investigating the non-stock scenario. However, it is my experience that if you record the invoice through open / pending invoices, there is no real difference in the way the workflow treats an invoice. I guess this is a good thing because you do not need separate workflows.

  5. Herre says:

    Some major flaws in the invoice workflow and approval process in standard AX. First of all the post function does not work when the invoice is registered in the register and them matched in the invoice and approved. Perhaps a bigger problem is that every unvoice approver, even if done in the enterprise portal, is a full enterprise user. Go do he maths when you have an organisation with between 200 and 300 approvers!

  6. Duncan says:

    Very interesting post, we are planning to use AX standard workflow to solve this in our solution and its good to get this overview as its not something I will directly work with but have an interest from my previous workflow development projects.

  7. Stacy says:

    Is there a method within workflow that an approver can approve specific invoice on a journal and return the others to the originator for corrections?

  8. Vivek says:

    Very useful blog….thanks for sharing your thoughts

  9. Allan says:

    Good article!!!

    In my experience the workflow functionality is not bad but is lacking the key elements that render it un-usable for major companies. We really need to be able to send direct invoices to a user in the business who is responsible for a cost centre or funciton based on a Financial Dimension (which is possible via Invoice Expenditure Reviewers) however the workflow should then traverse the position hierarchy based on signing limits. The workflow should also allow the user to update the Financial Dimensions (e.g. GL Account). At the moment we cannot use this functionality and need to use external Invoice scanning solutions to do this…


  10. emancalelletara says:

    Todos os dias você deverá executar os exercícios propostos sobre Calendário do Q48. Poderá narrar com para ajuda do Aplicativo para Smartphone e seguir o treinamento conforme lhe foi proposto.

  11. Pingback: Vendor invoice recording (Part 2) | Dynamics AX Finance & Controlling

  12. Pingback: Kreditorenrechnungserfassung (Teil 2) | Dynamics AX Finance & Controlling

  13. Pingback: Vendor invoice recording (Part 2) - Microsoft Dynamics AX Community

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s