Understanding Voucher Processing and the Voucher Life Cycle
After you have set up all your control information, established your PeopleSoft Payables control hierarchy, and entered approved suppliers in the system, you are ready to enter vouchers into the system.
This section discusses one method of entering vouchers into the system: using the online Voucher component. The pages in this component are the equivalent of electronic voucher forms on which you can record invoice information from your suppliers in the PeopleSoft Payables database. You can also quickly copy line item information from purchase orders and receivers from PeopleSoft Purchasing tables.
Note: For better performance, it is recommended to review or update large vouchers (with many lines/distribution) via voucher inquiry or voucher maintenance respectively.
Oracle also provides the Voucher Build Application Engine (AP_VCHRBLD) process for creating vouchers. This process builds and edits voucher records from various sources, including the Quick Invoice Entry (VCHR_QUICK_PNL) component, the Summary Invoice Entry (VCHR_SUMM_PNL) component, and the Spreadsheet Voucher workbook. The Voucher Build process, the Quick Invoice Entry component, and the Spreadsheet Voucher feature are discussed in other topics.
This section discusses:
Voucher process flow.
Voucher life cycle.
Voucher styles.
Voucher validation.
Voucher session defaults.
Processing that is initiated by the Voucher component.
(USA) Vouchers for Health Insurance Portability and Accountability Act of 1996 (HIPAA) payments.
The following flowchart illustrates the processing routes that a voucher can follow. It includes optional stages of voucher processing, such as creating control groups and applying matching rules to approve a voucher.
Vouchers go through several stages from initial entry to payment to posting. PeopleSoft Payables tracks these stages using various statuses for the following status types that relate to various actions and processes that can be run on a voucher:
Entry status.
Match status.
Approval status.
Budget status.
Document Tolerance status.
Post status.
Payment status.
Payment Post status.
This table illustrates the values for each voucher status, before and after processing:
|
Status Type |
Process |
Initial Status |
Post-Processing Statuses |
|---|---|---|---|
|
Entry Status |
Voucher Entry |
Open |
Deleted Recycle Postable |
|
Match Status |
Matching |
To Be Matched |
Exception Manually Overridden Manually Set to Credit Note Matched Match - Dispute No Match |
|
Approval Status |
Voucher Approval |
To Be Approved |
Pending Approval Approved Denied |
|
Budget Status |
Budget Processor (Budget checking) |
Not Checked |
Valid Error |
|
Document Tolerance Status |
Document Tolerance Checking |
Not Checked |
Valid Error |
|
Post Status |
Voucher Posting |
Not Posted |
Posted |
|
Payment Status |
Pay Cycle Payment Selection subprocess |
Not Selected |
Selected for Payment |
|
Payment Status |
Pay Cycle Payment Creation subprocess |
Selected for Payment |
Paid |
|
Payment Post Status |
Payment Posting |
Not posted |
Posted |
When you first enter a voucher into PeopleSoft Payables, it has an entry status of Open. When you save the voucher for the first time, the system validates the input with information that is provided by default from the control hierarchy to ensure correct entries. If the voucher passes all validations, it goes into a Postable state. The system generates accounting entries when the Voucher Posting Application Engine (AP_PSTVCHR) process selects the voucher for posting. At this time, the voucher is available for distribution to the general ledger using the Journal Generator Application Engine (FS_JGEN) process.
If one or more of the validations fail, a couple of events can happen. For some edits, the system does not allow you to save the voucher until the error condition is corrected. For example, if you do not enter a date on the voucher header, you cannot save the voucher.
For other edits, you can choose less restrictive error handling, such as Recycle, which lets you save the voucher. However, you cannot post or pay the voucher until you correct the error. You set these rules at the business unit level of the control hierarchy and can override them at other levels: voucher origin, control group, supplier, and voucher. With duplicate invoice checking, for example, you can choose recycle error handling, which means that the system accepts the suspect vouchers but does not enable them to be posted or paid. To post and pay these vouchers, you must update the voucher with correct information.
Until a voucher has been reviewed for approval, or unless it is preapproved, it has an approval status of Pending. After that, a voucher can be approved or denied. A voucher cannot be paid unless it has been approved. However, if your business unit definitions enable you to, you can post a voucher even though it has not been approved for payment.
When you post a voucher in PeopleSoft Payables, the system creates balanced accounting entries to record the liability and sets the post status to Posted. When a voucher is in a posted state, you can make only limited changes to it. Essentially, you can change only descriptive information that does not affect the numbers on the voucher. To change the numbers on a posted voucher, you must first unpost the voucher to create reversing entries. This action puts the voucher back into a postable state, as if it had never been posted. You can then change the necessary fields.
A voucher can have one or more payment records selected for payment based on their scheduled pay date and other parameters. The payment status is Unselected, Selected for Payment, or Paid.
Note: If you are using budget checking (through the Commitment Control feature), you cannot post or pay a voucher until it has successfully passed budget checking.
PeopleSoft Payables provides various voucher styles, each of which addresses a particular objective:
Term |
Definition |
|---|---|
Adjustments |
Enter adjustment vouchers for credit or debit memos, or for relating one voucher to another. This style is also used for debit memo adjustment vouchers that are created by the Matching Application Engine process (AP_MATCH). |
Amortization Voucher |
Enter amortization vouchers for creating accounting entries to amortize payments made in advance. You enter amortization information that will be used for managing the schedule of amortization. |
Journal Voucher |
Enter vouchers for adjusting accounting entries. |
Prepaid Voucher |
Enter prepayments (down payments, progress payments, or deposits). |
Register Voucher |
Accrue an individual voucher for which the expense distribution is not known or not yet approved. |
Regular Voucher |
Enter standard vouchers (this is the default setting). This style is also used to enter purchase order vouchers and vouchers that require matching to purchase orders and receiving documents. |
Reversal voucher |
Create a new voucher with reversal accounting entries and back out encumbrances. |
Single Payment Voucher |
Enter a voucher for a one-time supplier without having to define the supplier in the system. |
Template Voucher |
Create a voucher that can be used as a template for generating regular vouchers that share voucher data. |
Third Party Voucher |
Enter vouchers for charges other than merchandise charges, for example, freight-only vouchers. |
When you save vouchers, many edits and processes occur automatically. Any problems that PeopleSoft Payables detects with a voucher are brought to your attention so that you can fix them immediately.
Other edits that are specific to particular voucher styles, payment terms, and other circumstances are discussed in the sections about those styles and circumstances.
This section discusses:
Voucher field validation.
Financial sanctions validation.
Voucher Field Validation
The system performs a series of validation checks to ensure that you have completed all the fields correctly. Some of the validations that occur are:
Duplicate invoice checking.
Verifying the existence of a supplier ID.
Verifying the existence of an invoice date and invoice ID.
Balancing header amounts against voucher line amounts for both transaction and base currency amounts.
Balancing voucher line amounts against distribution line amounts for both transaction and base currency amounts.
Ensuring that the user ID that is approving the voucher is the same as the user who is signed in.
Validating accounting distribution field values and combinations and error processing.
Where appropriate, validating the calculation and proration of nonmerchandise charges, such as sales and use taxes, value-added taxes (VAT), freight charges, and miscellaneous charges.
Validating the bank ID, bank account number, and DFI ID.
Validating the payment limit set on the Payment Schedule Restrictions Page .
Validating that there is an entry on the Federal Payment Schedule Restrictions page.
Validating that the payment schedule amount does not exceed the amount defined for Same Day ACH Amount Per Payment.
Financial Sanctions Validation
PeopleSoft provides validation of your suppliers against financial sanctions lists (for example, the Specially Designated Nationals [SDN] list) at the supplier level, voucher level, and payment level. At the voucher level, if financial sanctions validation is enabled at the installation level, the invoicing supplier and remit supplier or suppliers, if different from the invoicing supplier, are validated. If financial sanctions validation is enabled at the bank level, no validation of the supplier is done during voucher processing unless you specify a bank for the remit supplier and the bank requires financial sanctions validation. The system updates the supplier's financial sanctions status on the Supplier Information (VNDR_ID) component.
At the voucher level, the system validates your suppliers upon:
Saving the voucher if financial sanctions validation is enabled at the installation level, or if financial sanctions validation is enabled at the bank level, you specify a bank for the remit supplier and the bank requires financial sanctions validation.
The system displays a warning message that the supplier is currently under financial sanctions review. You can proceed with saving the voucher; however, the system does not allow payments to suppliers with a financial sanctions status of Review or Blocked.
At the time of voucher entry, if financial sanctions validation is enabled and the supplier that you entered has a financial sanctions status of Review or Blocked, the system displays a warning message that the supplier that is selected is currently under financial sanctions review. You can proceed with adding or updating the voucher for this supplier.
Note: You cannot record a manual payment on the Voucher - Payments page if the supplier has a financial sanctions status of Review or Blocked. The system does not allow you to select Record as the payment action.
You cannot create an express payment on the Voucher - Payments page if the supplier has a financial sanctions status of Review or Blocked. The system does not allow you to click the Express Payment link.
Running the Financial Sanctions Validation Application Engine (AP_SDN_VAL) process.
You can schedule the Financial Sanctions Validation process to run on a predefined schedule using the Process Scheduler, or you can run it on an ad hoc basis.
You can define voucher defaults that automatically populate voucher fields for an entire session, and you can override those defaults for a particular voucher. These defaults override the defaults that the system applies using the PeopleSoft Payables control hierarchy. To set up voucher defaults, you can:
Predefine session defaults using the Session Defaults (AP_VCHR_DFLT_PG) page.
The system saves these defaults that you can apply to vouchers that you enter using the Voucher component or the Quick Invoice Entry component. You define session defaults for all users, for users with the same primary permission list, or for specific users.
Define ad hoc session defaults using the Session Defaults (AP_SESSN_DFLT_SEC) page within the Voucher and Quick Invoice Entry components.
The system does not save the defaults and only applies them during the current session.
Note: Session defaults can be applied only to vouchers with a voucher style of Journal Voucher, Regular Voucher, Single Payment Voucher, and Template Voucher.
Processing steps that occur when you save a voucher include:
Assigning a voucher ID for auto-numbered vouchers.
You can preassign voucher IDs on the add search page, as long as they are unique. In fact, if the auto-numbering option is disabled for the business unit, using the add search page is the only way to enter vouchers. Only the auto-numbered vouchers are assigned a voucher ID at save time.
Determining whether the status of the control group should be updated.
Setting one-time suppliers to inactive status.
Calculating and prorating the discount amount, if any.
Prorating sales tax, use tax, freight, and miscellaneous charges, as applicable.
Calculating and prorating VAT and sales and use tax (SUT) amounts.
Converting the transaction amount to the base currency.
Determining payment net and discount due dates.
Determining the scheduled payment date.
Creating payment records.
Performing withholding processing, as applicable.
Creating payment records for manual payments that are recorded on the voucher.
Checking the voucher match status.
Validating your suppliers if financial sanctions validation is enabled.
Voucher component-initiated processing that is specific to particular circumstances (such as integration with third-party tax applications or federal payment schedule processing) is discussed in the topics that cover those circumstances.
The Health Insurance Portability and Accountability Act of 1996 (HIPAA) is a set of regulations from the U.S. Department of Health and Human Services. One of the primary concerns of HIPAA is to restrict the use of individually identifiable health information to protect the privacy of healthcare consumers. In addition to the privacy rules, HIPAA includes regulations that establish national standards for the format and structure of electronic communications between covered entities.
PeopleSoft Payables generates HIPAA payments for only two transaction handling codes: Payment Only and Payment + Advice.
HIPAA entails communication protocol and standards for several business documents. PeopleSoft Payables supports Electronic Data Interchange (EDI) Format 820 (OUTBOUND), specifically designed for HIPAA required fields and values. To fully employ HIPAA functionality, you must use a third-party supplier to process the generated electronic funds transfer (EFT) file and transform it to the HIPAA 820 EDI format.
The HIPAA information that you define at the supplier level (in the HIPAA Information collapsible region on the Supplier Information - Payables Options page) appears by default on the HIPAA page in the Voucher component if the payment method for the voucher has an EFT layout of HIPAA. The system performs validation during online voucher entry and as part of the Voucher Build process, which checks for the HIPAA payment designation and marks such vouchers as Payment Separate.