Here is a list of terms and definitions that you will come accross when performing Accounts Payable transactions. Also see the Finance Glossary.
Enables users to control commitments and expenditures automatically by checking them against predefined, authorized budgets.
The process of editing journal lines for valid ChartField combinations based on university-defined rules.
Vouchers that are interfaced from external systems will be loaded into a Control Group to be verified by an appropriate department approver to validate the total voucher count and dollar amount loaded from the file. Control Groups will be loaded into the system with a ‘Ready to Review’ status. Once the Control Group is verified, users will change status from ‘Ready to Review’ to ‘Verified’. Upon status change, vouchers will be approved and will be available to be posted and paid
Duplicate Invoice Checking
Part of the matching process is to check that vouchers are not matching up with multiple invoices. This ensures that invoices within the system are not duplicates.
Indicates whether a voucher has been deleted, is postable, or has a recycle error that needs to be corrected
Ensures vendors are validated against the Federal Government Financial Sanctions List.
Matching process compares vouchers with purchase orders (2-way) and receiving (3-way) documents. This ensures that you pay for only the goods and services that you order and receive.
Generates payments through a standard process:
4. Process Generation
A voucher that is posted has passed all system validations and is ready for a payment to be generated and distributed from the voucher.
The voucher has passed all validations on the data entered on the voucher, including chartfields. Once a voucher is Postable, it can be posted to the GL after all approvals have been given. If the validation is unsuccessful, the voucher will go into a Recycled status, which prevents the voucher from being posted to the GL until the errors have been addressed.
Vouchers that fail edit check due to invalid data are stored on the Voucher Build staging table as a “Pre-Edit Error”
A voucher with a status of ‘Recycle’ lets you save the data. However, it cannot be paid or posted until the error is corrected.
Controls what level of access a user can have to pages and data in the system. Security ensures that the right people have access to the system screens and data to perform their job functions.
A user-defined shorthand key that designates several ChartKeys to be used for voucher entry
The Central Voucher Administrator must unpost a voucher in order to update voucher information as applicable. Once the voucher has been selected to be unposted, the user can indicate the accounting and reversal accounting dates before selecting Unpost
Users have the ability to record past vendor conversations/interactions in the ARC system to help inform others users of important relationship history with a particular vendor
The Voucher Build process validates the transaction data for pre-edit and recycle error and builds vouchers within the voucher tables
Voucher Build Error Detail
Users with the appropriate security level will be required to review and resolve any voucher data that was not successfully processed through the interface files through the Voucher Build Error Detail page
The voucher style will vary based on transaction type and purpose of the voucher. Voucher styles include: PO voucher, non-PO voucher, adjustment voucher, template voucher, reversal voucher, journal voucher, and single pay voucher
Withholding Mismatch Report
ARC will create a Withholding Mismatch report automatically each day. This report will help users identify voucher lines where the withholding flag does not match the vendor withholding flags
The Withholding Post process combines the voucher and payment information in the withholding/reporting transaction along with the following fields: 1099 type, 1099 code, reportable indicator, description, IRS file type, filing option, payer address, tax payer ID number, and transmitter control code
The routing of roles based on rules. Automatic, rule-based routing to pre-determined users based on criteria such as role, department, commodity, account, and dollar amount.
Informs users what transactions have been routed to them for approval/further action