Interesting Question From A Potential Customer…

“It would also help if you explained in details how the system works out approvals, e.g: individual limit, dep limit, PO rules limit, number of approvers…”

It’s worthwhile understanding that the system has been developed by looking at the real life purchasing scenarios that happen in most organisations. From our own experience over the past 7 years we found that the more complicated the process, the more it gets circumvented in practice as so the software has to be as simple as it can be.

With that in mind the system has been developed with certain assumptions to help this process:

1. Most people know  who to talk to about authorising a purchase for a department – as such they can select from a list very accurately. If its incorrectly forwarded to a user, that user can always forward it to the correct person.

2. Less than 5-10% of all purchasing is questionable: although user / department limits are important, it’s more important to make sure the right person analyses and approves the purchase after looking at it properly.

3. No one wants to get fired for authorising a high value purchase. If there’s any questions they’ll make sure to have them answered before clicking the “Create PO” button

4. No one has ever put together a high value purchase order without it being discussed several times a board / C level. As such you may not need as many approval levels as you think.

5. High level managers and board members quite often give their user credentials to their PA’s with the instruction to click the “authorise” button if they’re not around. Its best to keep the majority of authorisation requests slightly bellow this level for the most part.


The system doesn’t allow for user specified complex work flows to be created; you can not specify user A reports to user B who then reports to user C as this would need to be hard coded within the application. As our system works on dynamically selecting the correct approver depending on the user limits and security that’s been set up, to hard code this would break the logic. Having said that it does allow for a very robust and quick approval process by using multiple approvals, user limits and departments. This may make the set up and roll out slightly more complicated at the start but it also allows exceptions to be handled very quickly and simple which is the downfall of hard coding these values: authorising users being absent, additional users being added at any level within the system, users being removed Etc.

Approval works in the following way:

1. Firstly the user must have the ability to raise a PO for the department in question.

2. They will also need the ability to approve on behalf of that department. If that’s not been granted then they will have to get someone else to authorise the PO

3. The purchase must be less than their “per transaction” value

4. The purchase must be less that their monthly budget, and less than the total of all the PO’s they’ve raised or authorised that calendar month.

5. Finally, the purchase order value must be below the department’s budget and not push it over – even when added to all the other purchases for that month.

6. OPTIONAL – if there are multiple approvals needed then it has to go through steps 1-4 for each approver needed


Note – the system does not differentiate between users ordering for different departments. If a user can authorise £2K they can do this for ALL departments they authorise for – it cannot be set on a per department basis.