When creating submission policies, you can set restrictions on certain details to determine which details are considered "valid" or "invalid". What this means is if your account has 200 General Ledger accounting codes, and you want your spenders to only choose from around 20 codes, you can set these 20 codes as "valid" making the other codes "invalid".
What Fields Can You Restrict In Submission Policies?
In the submission policy, depending on what your business requirements are for employee spend, you can limit the submission policies fields to certain GL codes, Tags, Vendors and Tax Codes. This means you can restrict which of these accounting fields are valid or invalid.
You can also choose whether Receipts and Descriptions are required for all transactions, only transactions above an amount you define, or not required at all.
What Does It Mean To Restrict Submission Policy Fields
An example of this is, if your business had over 200 GL codes and/or 100 Tags but you have a submission policy for a specific team that only uses 10 of these GL codes and 5 of these tags, you can limit the submission policy so these employees can only pick from these predetermined "valid" GL codes and/or Tags.
How Do I Restrict Submission Policy Fields?
If you want to set your submission policies to restrict certain accounting fields such as specific GL codes, tags, vendors and/or tax codes, follow the instructions in the video below.
What Will This Look Like For The Spender?
When specific accounting fields are restricted, the spenders that have this submission policy connected to their card, or team, will only be able to select from the fields picked by the administrator when building the submission policy. This will ensure the employee does not have the ability to pick non-applicable accounting fields!
It is important to note, while spenders will only be able to see the restricted accounting fields, administrators will be able to change the transaction details after the employee codes it. This can lead to a "non-valid" accounting code being picked, leading to the transaction becoming "non-compliant".
Comments
0 comments
Please sign in to leave a comment.