Skip to main content
Solved

Invoice Posting Authorization by Authorization Assigning Rule instead of Automatic Authorization for some specific code part combinations

  • Oct 12, 2026 11:23 AM UTC
  • 3 replies
  • 61 views
Do Gooder (Partner)
Forum|alt.badge.img

A specific requirement from a client is to involve the activated Authorization Assigning Rule in the Posting Proposal and the status of the same to be “AwaitAuth” where the Finance users will authorize the invoice postings based on the code part combinations in the assigning rule.

However, the Posting Authorization is set to “Automatic Authorization” in the PO Matching in the company setup. Due to this, all the PO based invoices are receiving a status of “Auth” in the Posting Proposal and the assigning rule is not being considered.

The reason for this requirement is to validate those invoices where expense accounts on which period allocation is required are reviewed by Finance Manager before approval and voucher creation and all other invoices to go directly in “Auth” status and can be posted by finance users without any authorizations.


Is there a way to include the assigning rule in the Posting Proposal and the status of the same to be “AwaitAuth” by not changing the company setup?

Best answer by Thomas Peterson

Hi, 

This would require a test, but it should work. 

Set the authorization rule to include a specific authorizer where that authorizer has a very low allowed value - for example 10 is the max allowed value to be authorized. 

When the rule is triggered authorizer X and the other normal authorizers would be assigned.  Given authorizer X does not have valid limit (max is 10) that posting line may not be automatically authorized. 

It is important to test, as it’s possible that IFS may still auto authorize even if max is 10.  If that’s the case, my suggestion would be to log a case arguing that when a max is given, it should be followed.  

I may be mistaken, but … I somewhat recall having that failure to use the max in a previous version.  I’ll try and find some time to test. I know a client had a CRIM, but its’ worth testing and reporting if still an issue. 

Else, I’m sure we can find other ways to cause an authorization or other failure to stop the invoice from final posting. 

Best regards, 

Thomas

View original

3 replies

Superhero (Employee)
Forum|alt.badge.img+20
  • Thomas Peterson
  • Superhero (Employee)
  • Answer
  • Oct 15, 2026 3:52 PM UTC

Hi, 

This would require a test, but it should work. 

Set the authorization rule to include a specific authorizer where that authorizer has a very low allowed value - for example 10 is the max allowed value to be authorized. 

When the rule is triggered authorizer X and the other normal authorizers would be assigned.  Given authorizer X does not have valid limit (max is 10) that posting line may not be automatically authorized. 

It is important to test, as it’s possible that IFS may still auto authorize even if max is 10.  If that’s the case, my suggestion would be to log a case arguing that when a max is given, it should be followed.  

I may be mistaken, but … I somewhat recall having that failure to use the max in a previous version.  I’ll try and find some time to test. I know a client had a CRIM, but its’ worth testing and reporting if still an issue. 

Else, I’m sure we can find other ways to cause an authorization or other failure to stop the invoice from final posting. 

Best regards, 

Thomas

Do Gooder (Partner)
Forum|alt.badge.img
  • harshit.4191
  • Author
  • Do Gooder (Partner)
  • Oct 16, 2026 10:55 AM UTC

Hi Thomas,

Thanks for your response.
I forgot to tell you that the company setup also had “Inherit Authorizer(s) from Purchase” enabled.

Now, based on your response, I created three test cases and the response for each case is given below: 

Test Case 1 - The Posting Authoirzation is set as “Automatic Authorization” and “Inherit Authorizer(s) from Purchase” is enabled in the Company settings. The authorization routing rule has three authorizers (X, Y & Z) of which the authorizer X has a maximum amount allowed for authorization as 10. The routing rule is attached with an assigning rule in which the code part combination is the same as the code part combination in the Posting Line of the PO based Invoice. The posting proposal status is “Auth” in this case and the Authorizers from Purchase are followed and the Assigning Rule is not triggered.

Test Case 2 - The same setup as case 1 but “Inherit Authorizer(s) from Purchase” is disabled. The posting proposal status is also “Auth” in this case and the authorizers from Assigning Rule are fetched. In the Authorization Analysis, all three authorizers X, Y & Z are visible and the “Automatically Authorized” is “Yes” for the two authorizers Y & Z with no limit defined and “No” for the authorizer X with 10 as the limit.
I created one more case since the above cases failed.

 

Test Case 3 - The same setup as case 2 but the Authorizers Y & Z are removed from the Authorization Routing Rule.
In this case, the posting proposal with “AwaitAuth” status is seen. In the Authorization Analysis, the “Automatically Authorized” is “No” for the authorizer X and an error message was visible as “You cannot authorize the posting line because the amount to be authorized is higher than the allowed maximum amount defined for the authorizer in the Invoice Posting Authorizers window. Note that the posting line will not be acknowledged as well since there is no subsequent authorizer responsible for this posting line”.
In this case, the requirement is fulfilled as the status of the posting proposal is “AwaitAuth” but the authorizer now has to manually change the authorizer to some other authorizer who is having the allowed amount authorization for Final Invoice Posting.

Thanks again !!

Best Regards
Harshit

Superhero (Employee)
Forum|alt.badge.img+20

Thanks for testing. 

After a quick read, it looks like something you could automate.  Commonly if a user can do a process / step, that process / steps can be automated. If you can automate, then it should be a very easy process for the end users.   Common automation is obtained via the BPA. 

Best regards, 

Thomas

Terms & ConditionsAccessibility statement