Authorization limits on multi-lines invoices are checked once all lines in certain sequence (for example, approvers of Round 1) are authorized, which prevents all the approved lines from moving forward to the approvers of the second round, in case one or few rows have not been approved in time.

I suggest, as an option to the existing process, a possibility for the rows to be distributed to the next level as soon as they have been approved, each separately, with no regards to the approval status for the remaining rows. From our perspective, the faster the rows are forwarded to the next level, the better - as it looks now, this may improve our approval efficiency.

Example: a multi-row invoice, 10 rows, where each row is distributed to different cost center responsible (Dimension 2). 9 of ten 10 have been approved in Round 1 within 3 working days, while row 10 has not been approved by the 1-st Round approver in time for any reason. This makes that none of the 9 approved rows goes further to the next attest level. Finance team identifies the issue and resolves the issue with the missing row, which means that all the lines on the invoice have been forwarded to the next level and 5-10 new approvers will need to attest it. The current process may mean the risk that invoice is not even partially approved by the month end procedure or on due date by any of the senior management.

What we would like to achieve: possibility to get the lines to be distributed to the next level as soon as the row has been approved, each separately, with no regards to the approval status for the remaining rows. Applying this to the scenario above, that means that rows 1-9 most likely would have been finally approved within those 10 working days. The only issues that remains after ten days is the row 10. It is much easier to get one row approved rather than chase all the approvers of the 2-d or the 3-d Round for all the lines.

I understand that many companies can experience advantages with the existing process with validation on each sequence, therefore I would like to suggest this as an option to the existing process.