Vous êtes sur la page 1sur 38

Oracle Payables

Contents
Supplier........................................................................................................................4 Bank Account Model (R12)..............................................................................................4 Basic Invoice Cycle........................................................................................................4 Invoice Approval............................................................................................................6 Invoice Hold..................................................................................................................6 Memos.........................................................................................................................6 Scheduled Payment.......................................................................................................7 Cancel Invoice..............................................................................................................7 Reverse Invoice Distribution............................................................................................7 PO Default and Quick Match Invoices...............................................................................7 Invoice Matching...........................................................................................................7 Receipt and Perpetual Accruals.......................................................................................9 How to Match a Credit Memo to an Invoice in R12............................................................10 Prepayment................................................................................................................11 Allocation...................................................................................................................11 Freight.......................................................................................................................12 Mixed Invoice..............................................................................................................12 Taxed Invoice (11i)......................................................................................................12 Recoverable Tax.........................................................................................................15 How to Associate the Tax Line to an Invoice Line (R12)....................................................16 Withholding Tax...........................................................................................................16 Reportable Income.......................................................................................................18 Assets Integration........................................................................................................19 Recurring Invoice.........................................................................................................19 Expense Report...........................................................................................................19

3 Automatic Offsets........................................................................................................20 Automatic Interest........................................................................................................21 Pay on Receipt............................................................................................................21 Payables Integration....................................................................................................23 Payment Document.....................................................................................................24 Payments...................................................................................................................24 Refunds.....................................................................................................................25 Payment Batch............................................................................................................25 Stopping/Voiding Payment............................................................................................26 Payment Accounting....................................................................................................26 Future Dated Payment.................................................................................................27 Integration with Projects................................................................................................27 Supplier in R12............................................................................................................27 Payment Processing in R12..........................................................................................27 Bills Payable...............................................................................................................31 Create Accounting and Posting to GL.............................................................................31 Integration of Payables with Other ERP Modules..............................................................33 AP Period Closing Activities..........................................................................................33 Document Sequencing.................................................................................................37 Defaulting Hierarchy.....................................................................................................37 Defaulting Hierarchy

Supplier
Supplier Account Supplier account balance = Invoice Memo Payment Prepayment + Refund How to view Supplier Account Balance? Invoice Aging Report AP Trial Balance Report Online: Find invoice window Calculate Balance Owned Supplier Bank Account (11i) Needed for electronic payment Configured as bank account with account use as Supplier Multiple bank accounts may be mapped to a Supplier or Supplier Site The mapping between the Supplier/Supplier Site and the Bank Account can be done either in the Supplier form (Bank Accounts region) or in the Bank Account form (Supplier Assignments region). This is possible only if Payables Options.Use Multiple Supplier Banks = Yes. If No, can enter only a single bank for each Supplier/Site One of these bank accounts needs to be flagged as Primary for defaulting to the Payment Schedule. Supplier Merge 1. Merge duplicate suppliers into a single consolidated supplier (all or only unpaid invoices). In case of former, payments are merged as well. 2. Merge transactions within the same Supplier from one site to another. In the first case, you can choose to automatically create an existing site belonging to the old Supplier for the new Supplier.

Bank Account Model (R12)


In R12, Bank and Bank Branch are modeled as Parties under TCA. Bank Account usage may be any combination of the following: AP, AR, Payroll, Treasury

Basic Invoice Cycle


The following are the steps in the invoicing process Add invoice Validate invoice Create accounting for invoice Transfer invoice journals to GL

Pay invoice Create accounting for payment Transfer payment journals to GL

5 1. Add invoice You may add invoices singly or in batch depending upon the AP: Use Invoice Batch Controls profile option. In 11i, need to add invoice header and distributions. In R12, need to add invoice header, lines and distributions. Invoice line implies Goods, Tax or Freight. 1. Validate invoice Invoices may be validated online or through batch program On successful validation, payment schedules are added. Also automatic tax distributions are added If validation is unsuccessful, the invoice is held 1. Create accounting Sub-ledger journals (header and lines) for the invoice or payment are created. For every invoice distribution, one Accounting Entry (AE) line is created (11i). In R12, Create Accounting can be run under the following modes: a. Draft The accounting is only created in the XLA Subledger tables and is not transferred to GL. Draft accounting can be recreated based on changes to the transaction data or accounting rules. b. Final - Draft The accounting is created in the XLA Subledger tables and is not transferred to GL. Accounting created in final mode cannot be recreated/altered. Run the Transfer Journal Entries to GL program to transfer these entries from the XLA subledger tables to the GL tables. c. Final Post - The accounting is created in the XLA Subledger tables and is also transferred and posted to the GL tables. 2. Pay invoice Quick or manual payment or pay batch. (In R12, instead of pay batch, we have Payment Process Request). 3. Transfer to GL If the transfer is in Detail, there is a 1:1 correspondence between AE lines and GL lines. If transfer is in Summary (say Accounting Period), all AE lines having the same CCID and the same Accounting Period are clubbed together to form one GL line. The Detail/Summary flag is defined at Payables Option; overridden during program submission (provided Payables Option.Allow Override = Y); further overridden during Import journal at GL. In R12, because of SLA, you cannot specify this flag in a sub-ledger. However, the flag at Import Journal remains. The various possible invoice Actions are as follows: Validate Validate related invoices Cancel invoice Apply/Unapply prepayment Pay in full Create accounting. In R12, the various modes of this are: Draft, Final, Final Post Approvals: Force, Initiate Release holds

Invoice Approval
Workflow. Needed for invoice to be paid

6 Flagged at Payables Options (i.e. whether needed) Even if invoice is rejected within the workflow, user can do Force Approval (if enabled at Payables Options). On force approval, the invoice status becomes Manually Approved Invoice validation and approval may be effected either in parallel, or you may require to validate the invoice before approving it. The latter constraint is enforced through a Payables Options flag. Depending upon workflow parameter, PO matched invoices may be exempted from invoice approval. The Pay on Receipt AutoInvoice program creates invoices against existing uninvoiced Receipts.

Invoice Hold
An invoice may be held when you try to validate it. An invoice may have multiple holds. On being held, the status of the invoice becomes Needs Revalidation. Invoice holds may be of different types. They may be categorized according to 3 dimensions: Payment hold Vs Accounting hold. The latter prevents both accounting and payment. Manual hold Vs System hold. A manual hold can be released manually only, by attaching a Release Code to the Hold Code. System holds are released when the hold condition is corrected. However, some system holds may be removed manually as well. Where the hold is applied: An invoice hold may be applied at the scheduled payment or the invoice or the Supplier or the Supplier Site. For the last mentioned, the types of holds are: Hold all payments, Hold unvalidated invoices, Hold unmatched invoices, Invoice amount limit. If Budgetary Control is set up in GL, then as part of the validation process, AP checks whether sufficient funds are available for the individual distributions (i.e. CCIDs). If this fails, the invoice is held

Memos
Credit memo is Supplier initiated, while debit memo is user initiated Enter the memo header. Then add distributions. Distributions may be added in any of the following methods: Enter manually Match to invoice There is m:n cardinality between invoice and memo. Facility to pro-rate distribution amounts For inventory items, facility to enter credit quantity (amount will be calculated)

Scheduled Payment
In effect a Pay Term line

7 Can manually add, modify and delete Can pay and split a schedule Based on the Payables option flag Recalculate Scheduled Payments, the system can, on invoice validation, recalculate scheduled payments taking the more favourable of the Pay Terms defined at the PO and the invoice.

Cancel Invoice
On canceling an invoice, negative invoice distributions are created You can create accounting for the canceled invoice.

Reverse Invoice Distribution


You cannot reverse PO matched invoice

PO Default and Quick Match Invoices


Entered against a particular PO. After getting saved, AP stores such invoices (Mixed invoices as well) as Standard invoices.

Invoice Matching
Invoiced or billed items are matched to the original purchase orders to ensure that you pay only for the goods or services you ordered and/or received. If you are billed for an item over the amount and quantity tolerances you define in the Invoice Tolerance window, during Approval, Oracle Payables applies a hold to the invoice, which prevents payment. In R12, matching may be at the level of invoice line too, in addition to the invoice header. Match Approval Level 2-Way: (Invoice Quantity Vs PO Quantity) + (Invoice Price Vs PO Price) 3-Way: 2-Way + (Invoice Quantity Vs Receipt Quantity) 4-Way: 3-Way + (Accepted Quantity Vs Invoice Quantity) This option can be setup as a default in Purchasing Options, Supplier or Supplier Site or on the PO Shipment Line. Match Option can be either at PO or at Receipt When matched against PO, the following records are updated: PO Shipment.Quantity Billed, PO Distribution.Amount Billed When matched against Receipt, in addition to the above records, the rerecord Receiving Transaction. Quantity Billed is also updated. This option is available in the PO Shipment form Invoice Match Option. If you are using 4-way matching you must also enable inspection of the goods when they are received. To do this you can set the default in Receiving Options or set inspection at the PO Shipment level. (In Purchasing, Setup > Organizations > Receiving Options > Receipt

8 Routing) Note that to require inspection, receipt routing should be set to inspection required. You can match a single invoice to multiple purchase order shipments, or you can match multiple invoices to a single purchase order shipment. Oracle Payables ensures that you match only to purchase orders for the supplier on the invoice and that the purchase order and invoice currencies match. Add invoice header Match invoice (including entering Quantity) Distributions get created (derived from PO) Validate invoice Invoice held if not within matching tolerances Example: $137 invoice. Match $100 to item. Allocate $10 to tax, $15 to Freight, $12 to Miscellaneous You need to define a number of variance accounts. (In Purchasing, Setup > Organizations > Organizations). Place your cursor on the inventory org and click the others button. Select Inventory Information. Select alternate region other accounts. Purchase Price Variance Account. This account shows the variance between the purchase price on the purchase order and the standard cost for all items you receive and deliver into inventory and work in process. Inventory records purchase price variance on delivery into a subinventory. Work in Process records purchase price variance on delivery into the job or repetitive schedule. Invoice Price Variance Account. This account shows the difference between the purchase price on the purchase order and the purchase price on the invoice. Variances Invoice Price Variance = (Diff in price)*(Invoice Qty). Note that the Price hold is because the average price of all the invoices matched to the PO is compared to the PO price. Invoice Quantity Variance = (Diff in Qty) * (PO Price) Payables Options flags Allow Final Matching. Select this option to allow final matching of purchase order matched invoices. You can indicate a final match when you match an invoice to a purchase order during invoice entry or when you adjust a matched invoice distribution. Select this option only if you want to allow the option of permanently closing the purchase orders. Allow Distribution Level Matching. Select this option if you want to allow matching to purchase order distributions. Allow Matching Account Override. Select this option if you want to allow override of the account for an invoice distribution created from matching to a purchase order. You cannot override the account for a matched invoice distribution if you use encumbrance accounting or perpetual receipt accrual. Transfer PO Descriptive Flexfield Information. Select this option if you want to automatically transfer the descriptive flexfield information from the purchase order distribution to the invoice distributions when you match an invoice to a purchase order. Invoice Tolerances are defined to allow for variances between invoices and purchase orders and for differences in tax calculation. If a tolerance is exceeded, the invoice will go on hold during the invoice approval process. If an invoice is on hold, the invoice cannot be paid. In the Invoice Tolerances window, select the check box for each tolerance you want to enforce, and enter tolerance levels for your purchase order matching transactions

9 and your invoice taxes E.g. Inv Qty Vs PO Qty, Inv Amt Vs Shipment Amt, Inv Qty Vs Rec Qty This form also displays the name of the Hold that Oracle Payables will place on the invoice for each tolerance that is exceeded. You set tolerances to specify the range of variance you will allow if the amounts or quantities on the invoice are greater than the amounts or quantities on the purchase order or receipt but not the other way round. It should be noted that accounting entries are generated when the receiving transaction processor is run. The process transfers the accounting entries to the GL_INTERFACE table where General Ledger can import the transactions and then post them to the general ledger. The profile option RCV: Processing Mode determines when the receiving transaction processor is run. There are three values for this profile option, on-line, immediate and batch. If you select online or immediate, the receiving transaction processor is kicked off as soon as the receipt is saved. If you select batch, then you must run the process as a concurrent request. In order to transfer descriptive flexfield information from Purchasing to Payables when matching invoices, the following conditions should be met: Enable the Transfer Descriptive Flexfield information Payables Option Enable the same flexfield structure at the invoice-line level and PO-distribution level. QuickMatch - Payables automatically completes the match to all available shipments on the purchase order, and automatically creates invoice distributions on the basis of the purchase order distributions.

Receipt and Perpetual Accruals


Inventory items are always accrued at Receipt (Perpetual Accrual). Expense items may be accrued at Receipt or at period end, depending upon the Purchasing Options flag Accrue Expense Items For accruals generated at receipt, the accrual is automatically sent to General Ledger and subsequently cleared when an invoice is entered and matched to the purchase order. The following are the various accounting events for Perpetual Accrual: Dr Receiving Inspection Cr Inventory item: Inventory AP Accrual Expense item: Expense AP Accrual No entries Receiving Inspection Price PO

Event Receive

Inspect Deliver to Final Inventory or to Expense Distribution

Inventory items: Subinventory account (defined during Transfer) Expense items: Charge account (as defined in PO distribution)

Standard Cost (For inventory items, if Standard Costing is followed. Spawns Purchase Price Variance)

Encumbrance

Reserve for Encumbrance

10 Invoice Inventory/Expense AP Accrual AP Invoice Price (spawns Invoice Price Variance)

Purchase Price Variance = (PO Unit Price Standard Unit Cost) * Qty Received Invoice Price Variance = (Invoice Price PO Price) * Qty Invoiced For accruals generated at period end, the accrual is sent to General Ledger after the Receipt Accruals - Period-End process is run and the accrual is cleared when the journal entry is reversed in General Ledger. Dr Expense/Clearing Cr Expense AP Accrual As part of it's closing process, XYZ Corporation reviews receipt accruals. Occasionally Payables matches incorrectly, and as a result they find that some perpetual accruals never clear, leaving reconciliation items on their accrual reports. Which two actions should the company take to solve the problem? Reverse the invoice distributions and rematch if possible. Run the Accrual Rebuild Reconciliation report to identify the receipt accrual that has not cleared and use the Write-Off window to remove the item from reappearing on subsequent reports. Then, create a manual journal entry in General Ledger to clear the accrual.

How to Match a Credit Memo to an Invoice in R12


There are 2 ways: Quick Credit functionality Using the Correction button Note: 1. If you choose Match Action as Invoice, you can do only Amount correction (for a CM. In case of Invoice, it is greyed out if Match Action is Invoice). On the other hand, if you choose Match Action as either PO or Receipt, you can do Price and Qauntity Correction as well. But the invoice should, in such cases, have a PO (a Receipt as well, if Match Action is Receipt) 2. You can match at either the invoice header or the line level. In case of the former, the system generates both lines and distributions. In case of the latter, the system generates distributions. 3. If you wan tot match an invoice to PO/Receipt, the Matching type can be either of the following: Item, Freight, Miscellaneous, Tax. In case invoiced Supplier of the latter 3, the Supplier may be different from the invoiced supplier i.e. you are matching the non PO suppliers invoice/line to the PO Suppliers Freight/Miscellaneous/Tax.

Prepayment
Enter Prepayment invoice of type Temporary (including Settlement Date) Pay in Full Status of the Prepayment invoice becomes Available Apply the Prepayment invoice to

11 one or more invoices on or after the formers Settlement Date Status of the Prepayment invoice becomes Fully Applied Example: If PPI = $100 and applied invoice = $500, then on application, a negative distribution of $100 will be added to the applied invoice (same CCID as PPI) Accounting treatment Cr AP Amount 100

Event Add PPI ($100)

Dr Prepayment (from Supplier Site or Payables Document, depending upon Payables Option flag) Pay PPI AP Enter invoice ($500) Expense and apply AP

Cash AP Prepayment

100 500 100

A prepayment can be matched to a purchase order. The match is treated as a reservation of the quantity billed. When the matched prepayment is applied to an invoice, the matched quantity on the prepayment is backed out of the PO to reflect the balance of total quantity matched. A prepayment can be matched to a receipt. Prepayments matched to receipts behave the same way prepayments are matched to purchase orders. The receipt matching is back out. A prepayment can be applied to an unapproved invoice. When a prepayment is applied to an invoice, which has a discount, the discount on the invoice is calculated net of prepayments. You can adjust the discount amounts as needed. Invoice tax is calculated net of prepayments. If automatic tax calculation at the line level or tax code level is used, and prepayments are applied before the tax is calculated then Payables calculates the tax amount net of the prepayment application. If you use header level tax calculation, you might need to manually adjust the invoice amount and tax amount if the Prepayment distribution has a tax code assigned. If you use Automatic Offsets then your setting for the Prevent Prepayment Application Across Balancing Segments Payables option, controls whether you can apply a prepayment to an invoice or expense report with a different balancing segment.

Allocation
Allocate invoice level charge (e.g. Freight/Tax) to selected distributions under the invoice. For every mother distribution, one allocation distribution (of same CCID) will be created. Example: Invoice level charge = $100. Distribution 1 = $30, Distribution 2 = 0, Distribution 3 = $50, Distribution 4 = $20 The allocation can be prorated to the selected distributions as well.

Freight
If enabled at Payables Options, the system will automatically create freight distribution, using the Freight amount entered at invoice header, and the freight account. The latter is defined at the Payables Options, and can be overridden at the invoice

12

Mixed Invoice
Invoice or memo for which you can do both positive and negative matching to POs and other invoices.

Taxed Invoice (11i)


Payables Options for Tax: Require tax entry at invoice header (Yes, No) Automatic tax calculation (Yes, No). If Yes, If enabled at Payables Options, system automatically calculates the tax (based upon Tax Code) and creates distributions. Also if Yes Calculation Level (Header, Line, Tax Code). For the last two, the distributions are based upon invoice distribution. Calculation Level Override (Yes, No) Distribution Amounts Include Tax (Yes, No). If Yes, The amount of the distribution depends upon mother distribution.Includes Tax. Also if Yes Whether can be overridden at invoice level

the tax tax

tax

These options are detailed below. Require tax entry at invoice header If you enable this option, Payables requires you to enter a Tax Code and Tax Amount in the Invoices window when you enter an invoice. This option does not apply to any imported invoices or to credit and debit memos that are entered in the Invoice Workbench. If you use Automatic Tax Calculation at the Header level, Payables automatically calculates a Tax Amount. You are required to enter a tax code only if one has not defaulted from a source designated in your tax hierarchy. If you have enabled this option and the invoice has no tax, in the Invoices window you enter a Tax Code with a zero-percent tax rate assigned to it. You cannot enable this option if you select Line or Tax Code as your Calculation Level Payables option. If you allow override of the tax calculation level and you enter an invoice using Line or Tax Code level calculation, Payables will not require you to enter a Tax Code or Tax Amount in the Invoices window even if you have enabled the Require Tax Entry at Header option. Do not enable this option if you want to enter Use type tax codes on invoices. If you enable this option, Payables prevents you from entering Use tax codes on invoices. In addition, when you enable this option and enter a Use type tax code as the default tax code for a supplier site, Payables does not assign the default to the invoices you enter for the supplier site. You may not want to enable this option if you want to allocate tax across selected invoice distributions. If the Require Tax Entry at Header Payables option is disabled when you enter an invoice, then the Tax Code and Tax Amount fields are optional. Note that if you enable this option and if you process expense reports in Payables the import program will reject any expense reports that do not have at least one tax line. If an expense report has no tax, you can enter a zero amount line with a zero rate tax. Automatic Tax Calculation If you use automatic tax calculation, Payables calculates the invoice sales tax and automatically creates tax distributions. There will be one tax distribution for every unique combination of Tax Code + Account
Header Level Calculation If the needs of the user are simplistic, then header level calculation is a fast calculation and tax-

13
line entry vehicle. It calculates an inclusive tax amount based on the total invoice amount and creates a single tax distribution line which has the GL account of the tax code. In release 11i, if the Payables option Enable Recoverable Tax is on, header level calculation can be used only with tax codes which are 100% recoverable (For nonrecoverable lines, it wouldn't know which GL account to charge it to since that is based on the GL account of the item lines and those don't exist yet at the time the tax line is created.). Enabling the Payables option Exclude Tax from Discount only works (without manual intervention) with header level calculation. The Discountable Amount on the invoice header is simply the invoice amount less the tax amount, so if automatic tax calculation other than header is used, the system doesn't know how much to exclude unless the user manually fills in the tax amount. Distribution Level Calculation If the user needs more sophisticated tax calculation, then he may choose to use either Line or Tax Code level, both of which are at the distribution level. Distribution level calculation gives more flexibility (and more complexity) to the administrator, although, depending on the setup, may be no more difficult for the end user. Tax lines will be created either when the Calculate Tax button on the Distributions window or, in release 11i, the OK button on the Tax Summary window is pressed. If the user does not do this then the calculation will be done during approval. Once the tax is calculated for a line, a flag (TAX_CALCULATED_FLAG) is set to Y and that line will never go through automatic tax calculation again, even if something on the line is manually updated. Tax Code level and Line level calculation are the same except for how Payables groups and rounds tax amounts. In some cases, the tax calculation results are the same. When the results are different, the difference is usually a very small amount caused by rounding. The results between Tax Code and Line level calculation will differ if at least the following conditions are true: 1. The Enable Recoverable Tax Financials option is enabled. 2. The invoice has more than one Item distribution subject to tax.

3. At least one of the Item distributions uses a tax code that is partially recoverable
Inclusive vs. Exclusive Tax A: Payables can calculate tax either inclusively or exclusively. The decision of which to use depends on how the invoice itself breaks out the tax. Generally, VAT is shown inclusively. For example, a label on a store shelf shows an item as being GBP 100. This means that the buyer takes the good to the cashier, pays exactly GBP 100, and walks out the door. Assuming a 10% (inclusive) VAT, the item actually cost GBP 90.91 and the tax was (90.91 * 10%), or GBP 9.09 after rounding, but those numbers may not show anywhere on the receipt or invoice. When a Payables clerk enters the invoice, he only knows the total (inclusive) amount and the tax rate, but not explicitly the item or tax amount. This can be a useful way to have tax calculated even in the United States where exclusive tax is the norm. When several goods are purchased on a single invoice, the item amounts may not be subtotaled. For example, you receive an invoice for $102.80 which includes three items (10.28, 56.92, and 25.70) which all are to be charged to the same GL account, and a tax line of $9.28 which is applicable to all three items. Assuming you wanted the system to calculate (and enter) the tax automatically, the entry choices would be: 1. to enter all three items as individual distribution lines, then calculate tax exclusively 2. to manually add up the three amounts (or to subtract the tax amount from the invoice amount), enter a single distribution line for $92.80, then calculate exclusively 3. to enter the total (which appears on the invoice anyway) of $102.08, then calculate inclusively

14
Clearly the third choice would take the least time. When the user pushes the Calculate Tax button in the third scenario, the system would use the following formula: To achieve the following calculation: $100 / (1.10) = $92.80 The system would change the Item line amount from $102.08 to $92.80 and create a second line, a Tax line, for $9.28. Notice that, with inclusive tax, the invoice total and the distribution line total are $102.08 both before and after the tax is calculated. This is not the case for an exclusive calculation. In an exclusive entry, the clerk would enter an Item line for $92.80. At that moment, even though the clerk is done with the invoice, there is a distribution variance because the invoice total is $102.08 while only $92.80 has been entered in the distributions window. Then the Calculate Tax button is pushed and the system creates the Tax line for $9.28 using the more intuitive formula of: exclusive amount * tax rate = tax amount. Now that the Tax line has been created, the invoice is once again in balance and no distribution hold would be placed during approval. (If the tax lines are created during Approval, they are created before the checks for variances are done.) You can change the calculated tax amount provided it is within tax tolerances (as defined at Payables Options) Offset tax: Offset taxes are negative-rate taxes. In the Tax Codes window you can associate Offset taxes with Sales or User-defined taxes. When you use the Sales or Userdefined tax on an invoice, you record the tax, but the associated Offset tax reduces or eliminates your tax liability. To associate an Offset tax with a Sales or User-defined tax, first define the Offset tax. Then when you define the Sales or User-defined tax, enter the Offset tax code in the Offset Tax field. For this: Supplier Site.Use associated Offset tax = Yes For a positive Tax Code, attach an Offset Tax Code. Then during invoicing, when you enter the positive Tax Code in the item distribution and press Calculate Tax, the pair of positive and negative tax distributions will appear. Use Tax: To record a use tax you pay to a tax authority instead of a supplier, assign a use type tax name to the invoice distributions that are taxable by the use tax. Payables records the tax you owe the tax authority based on the use tax names tax rate and account. You do not create a tax distribution for the use tax, because tax distributions record supplier liabilities. To review your use tax liability, run the Use Tax Liability Report.

Tax Default Hierarchy: You define the Tax Code Defaults to determine the order in which Payables searches for tax codes when a Payables document requires a default tax code. This hierarchy is defined in two places: PO>Setup>Organizations>Purchasing Options> Tax Default (alternate region): Shipto location, Item Supplier site, Supplier, Financial Option AP>Setup>Options>Payables>Tax Name Defaults(alternate region): PO for Matched Invoices, Supplier Site, Supplier Account, Financial Option, Invoice Header, Template These hierarchies must agree and must have a value for each source that is enabled. If the hierarchy position for any enabled field is left blank it will be used before any source which is identified. You will be allowed to override the Tax Code at the invoice distribution only if the profile option Tax: Allow Override of Tax Code is enabled What is the significance of GL account (say X) defined at Tax Code? For non-WHT, Recoverable portion of the tax is distributed to X (The nonrecoverable portion is charged to the charge account)

15 For WHT (say 10%) For Supplier Dr Charge 500

Cr Liability 450 Cr Auto WHT 50 (distributed to X) Cr Liability 50

For Tax Authority Dr Charge 50 (distributed to X)

Tax Group
Used in AR 198615.1

Recoverable Tax
Recoverable tax implies the input tax in a VAT regime. In case the corresponding Output Tax is partially recoverable, the Input tax is also partially recoverable. The non-recoverable portion of the tax is considered as part of the acquisition cost of the item with corresponding implications in Encumbrance Accounting and transfer to PA/FA Recoverable Tax is distributed to the Tax Code account. Non-recoverable Tax is distributed to the charge account Pre-requisite: Enable the Enable Recoverable Tax flag at Financial Options. A tax code can have either a recovery rate or a recovery rule. Recovery Rate is the fixed rate at which the tax is recoverable. A default value is entered by the system from Financial Options (Setup->Options->Financial) if one has to be entered. The Recovery Rate value defaults to new purchase orders and invoice distributions where you can override these options only if the Tax: Allow Override of Tax Recovery Rate profile option is enabled Rule Name is the tax recovery rule name that determines the tax recovery rate based on account ranges, effective dates, and conditions such as supplier type. For a Recoverable Rule: Input parameters are distribution account range, invoice date, Supplier Type Recoverable Rate may be either fixed or a PL/SQL function

How to Associate the Tax Line to an Invoice Line (R12)


To allocate the tax through the tax details window, the following options have to be checked for override and manual entry: 1. Allow entry of manual tax lines at Regime level 2. Allow override for calculated tax lines at Tax level 3. Allow Tax Rate Override at Status level 4. Allow Ad Hoc Rate at Tax Rate level Also see if the Allow override and allow entry of manual tax line option is checked at the Configuration owner option level for the relevant OU/LE.

16

To allocate the tax line, follow the steps below: 1. Enter invoice header and item lines 2. Click on Tax Details and enter a manual tax line. 3. Click on Allocate button and allocate the tax line to the lines you want to. How to Enter a Tax Only Invoice the appropriate distribution account. Automatic Tax Calculation At the invoice line, enter the Tax Classification Code and press Calculate Tax (or validate the invoice line). A tax line will be generated. It will have 2 distributions of type Recoverable Tax and Non Recoverable Tax.

Withholding Tax
User actions: Enable WHT at Payables Options and at Supplier Map WHT to Tax Supplier in WHT form Enter invoice for Supplier with the WHT Group in invoice distribution Assign WHT Group to invoice or invoice distribution (default at Supplier Site) During invoice validation or payment processing (depending upon Payables Options flag), WHT distributions are automatically generated (negative amount). This distribution amount is not included in the Distribution Total for the invoice. In addition to creating WHT distributions. AP updates Invoice.Withheld Amount and reduces Scheduled Payment Amount. Also AP creates an invoice for the tax authorities either during invoice validation or payment processing, depending upon Payables Options flag. The type of the invoice is Withholding. The WHT invoice generated has the same distribution as the WHT Code Setup required: Payables Options Enable WHT and configure timing of WHT distribution and WHT invoice PO.Lookups Add Pay Group (unique) for each tax authority Enter each tax authority as supplier, with Supplier Type = Tax Authority. Assign the unique Pay Group to the Supplier. Also enable WHT for the Supplier. In R12 only Assign a Payment Format to a Payment Process Profile that uses Tax Authority Remittance Advice as its separate remittance. Define WHT type Tax Codes and Tax Rates. Assign Tax Authority suppliers to theTax Codes Define WHT Groups (for withholding multiple taxes per invoice, each payable to a different tax authority) Enter WHT details for Supplier WHT Certificates and Exceptions (for exemption at Supplier Site level) Paying tax authority refer to the User Guide

17 Accounting for WHT Say WHT GL account = X For Supplier ($500 invoice, 10% WHT) Dr Charge 500 Cr Liability 450 Cr Automatic WHT 50 (distributed to X) For Tax Authority Dr Charge 50 Cr Liability 50 (distributed to X) Thus balance in X is netted out You can use automatic withholding tax on prepayments in the same fashion as standard invoices. A reversal line for the withheld tax amount is inserted and a withholding invoice is created according to the system options. The timing of prepayment application is important when using automatic withholding tax: - If you have the Withholding Tax Payables Option set to Apply Withholding Tax at Invoice Approval Time, and you apply the prepayment before Approval, the withholding tax is calculated net of prepayments.

If you submit Approval before you apply the prepayment, you must adjust the withholding tax amount. You must also adjust the withholding invoice if your Withholding Tax Payables Option is set to Create Withholding Invoice at Invoice Approval Time or At Payment Time.

18

You need to add a Withholding Tax distribution line for negative $10 on the invoice. Then, adjust the invoice and distribution amount on the Withholding Tax invoice to be $10.

Reportable Income
Within an invoice, you may attach Income Tax type (defaulted from the Supplier) to selected distributions. At end of the year, you generate 1099 reports according to Income Tax Type. (Pre-requisite: Supplier needs to be flagged as Reportable)

Assets Integration
Pre-requisite: Distribution CCID must be configured as Asset Clearing account or CIP clearing account of any Asset Category in FA Similarly if the invoice is a PO matched one, the PO distribution needs to be Asset Clearing account or CIP clearing account of any Asset Category in FA Add and validate invoice Create Accounting Run Mass Additions Create program (for a particular Book) Invoice distributions populate the FA interface table The remainder of the process is carried out in FA Derived from invoice: Asset value, Date Placed in Service. Derived from PO: No of units

Recurring Invoice
Flow: Define Recurring Invoice template Recursively do a Create Recurring Invoice Unvalidated invoice gets created (Source = Recurring Invoice) Recurring Invoice template example Calendar = XYZ, No of periods = 6, first period = Aug 2011 Control total = $700, first amount= $200 (amount for remaining periods pro-rated)

19 Liability account = 567, Distribution Set = DS1 The Recurring Invoice template has a check box Approval Workflow Required. If it is unchecked, recurring invoices are not subject to Invoice Approval workflow.

Expense Report
Flow Add template Add expense report (including invoice no) Run Expense Report Import program Invoice gets created An expense report contains multiple items e.g. Airfare, Accommodation, Meals. It is defined under a template, which determines which items can be used in the report You need to configure the employee as a Supplier in AP. Alternatively, the application will do this for you when you run the program, if you enable the Payables Options flag Create Employee as Supplier. You can apply advance (Prepayment Invoice - PPI) against the Employee Expense in the Expense Report window e.g. you paid an employee $500 advance for travel. The employee later files an expense report of $1500. In that report, you apply the $500 PPI. On Expense Report import, $1500 invoice is created with a prepayment application of $500. The prerequisite for this is that the Payables Options flag Apply Advances should be enabled. The status of the Prepayment remains as Available till the associated Expense Report is imported to Payables. Expense report invoices are not subject to invoice approval workflow. During the entry or update of expense reports in the Payables Expense Report window, holds can be applied on an expense report. These holds are carried forward to the invoice created from the expense report in Payables.

Automatic Offsets
If you enter invoices for expense or asset purchases for more than one balancing segment, you may want to use Automatic Offsets to keep your Payables transaction entries balanced at the balancing segment level. For an invoice, Payables creates offsetting liability distributions; for a payment, Payables creates offsetting cash and discount taken distributions. This helps to ensure that each set of accounts remains balanced by balancing segment. By enabling Automatic Offsets within Payables, Payables will automatically allocate the liability, discount taken, and gain and loss entries for a given invoice across multiple balancing segments, according to the balancing segments of the invoice distributions. If you do not enable Automatic Offsets, Payables records the liability, cash, discount taken, and gain and loss entries in the accounts you specify in the Payables Options and Banks windows. These accounts have one balancing segment each Alternatively, you can set up Intercompany Accounting in Oracle General Ledger so that General Ledger automatically creates the intercompany accounting entries necessary to balance a transaction at the balancing segment level. If you choose to use Intercompany Accounting rather than Automatic Offsets, your Payables transactions that cross multiple balancing segments will not balance at the balancing

20 segment level until you transfer them to General Ledger and submit the Journal Import program. When you use Automatic Offsets and submit Approval for an invoice, Payables automatically builds the offsetting liability account for each invoice distribution There are 2 methods for automatic offsets: Balance and Account For the Liability account, the balancing segment value is always taken from the charge distribution, so as to keep the invoice balanced. The natural account value is always taken from the default Liability account as defined in the Supplier site. As for the remaining segments, values are taken from the charge distribution for the Balance method, and from the default Liability account as defined in the Supplier site for the Account method. If you have elected to use Automatic Offsets, we recommend that you not enable Create Summarized Journal Entries located in the Journal Entry Creation Region of the Payables Options form. Rather, post your invoices and payments in detail when you submit the Transfer to General Ledger program. Payables will then create journal entries with your invoice and cash distributions in detail. This will allow you to drill down from a general ledger account balance to specific transactions in Payables. If you enable Automatic Offsets, you cannot use any of the following Payables options: Allow Adjustments to Paid Invoices Allow Reconciliation Accounting Automatic Withholding Tax When Automatic Offsets is used, Payables automatically creates cash, discount and gain/loss distributions for each balancing segment when you create a payment using a pooled bank account. Payables uses the cash account you define for the bank account with the Automatic Offset Method you choose in the Payables Options window to create the cash payment distributions. If you don't use Automatic Offsets or create a payment using a nonpooled bank account, Payables creates payment distributions using a single account of each type. When you distribute an invoice across multiple balancing segments, the invoice will not balance by balancing segment. If you do not enable Automatic Offsets, you can only have nonpooled bank accounts. If you selected Balancing as your Automatic Offset Method, Payables takes the cash account associated with your pooled bank account, substitutes the balancing segment from the Invoice distribution and uses that as the distributions offsetting cash account. If you selected Account as your Automatic Offset Method, Payables takes the account used for the invoice distribution and substitutes the account segment from the cash account associated with your pooled bank account, preserving all other segment values.

Automatic Interest
Interest invoice is automatically created when an overdue invoice is paid through Pay Batch or Quick payment (not Manual), provided the flag Allow Interest Invoices is enabled at Payables Options. An overdue invoice may have multiple interest invoices. The Pay Term of Interest invoices is Immediate.

21 Interest rates need to be defined according to date ranges, in the Interest rates window. Expense and liability accounts are defined at Payables Options. Refer to User Guide for interest formulae Automatic interest invoices are one of 3 types of invoices that are automatically (i.e. without manual intervention) generated, the other 2 being Withholding Tax invoices and Pay on Receipt invoices.

Pay on Receipt

22

Payables Open Interface Import


C:\Users\ Adm inistrator\Desktop\Oracle\Metalink downloads\AP\Pay_on_Receipt.doc

Enter expense report Oracle Self Service Expense Invoice Expense Report Import Interface tables Expense report

Invoice Gateway XML Invoices


PCard Invoices

Oracle e-Commerce Gateway


EDI gateway Invoices

Oracle iSupplier Portal Feeder systems Oracle Property Manager

Pay on receipt invoices Credit card transactions Payables Open Interface tables (Header, Line)

Lease Invoice

Import program (run according to Source)

Oracle Payables (Header, Distribution, Payment Schedule)

Lease payments Oracle Assets The Payables Open Interface Import Program is used to create Payables invoices from invoice data entered in the following Payables Open Interface tables: AP_INVOICES_INTERFACE and AP_INVOICE_LINES_INTERFACE. These interface tables can be populated with invoice data coming from the following sources: Quick Invoices: Standard and Credit invoices can be entered in the Quick Invoices window. Invoices loaded from other accounting systems with a custom SQL*Loader program. Supplier invoices transferred through Oracle e-Commerce Gateway Credit Card transactions transferred using the Create Procurement Card Issuer Invoice program. Lease invoices transferred from Oracle Property Manager. Lease payments from Oracle Assets. Note that expense reports entered from a non-Oracle system will be interfaced through the Payables Open Interface, not the Expense Report Import interface

23 There are three additional reports associated to the Payables Open Interface Import program: Payables Open Interface Import Report -> child report of the Payables Open Interface Import Program. This report is used to review detailed information for each invoice imported during Payables Open Interface Import process. This report has two sections: 1) Payables Open Interface Audit Report -> displays the invoices successfully imported during import process 2) Payables Open Interface Rejections Report -> displays those invoices that Payables was not able to import. It also lists the rejection reasons to be corrected. Payables Open Interface Outbound Advice -> standalone report to be manually submitted by the user. This program creates notification data about e-Commerce invoices processed during Payables Open Interface Import. Payables Open Interface Purge -> standalone report to be manually submitted by the user. This report is used to purge records from the Payables Open Interface tables. We strongly recommend to purge only invoices successfully imported setting the 'Purge All' parameter to No. Setting this parameter to Yes purges all records in the Payables Open Interface tables. You can update records in the Open Interface tables through the Open Interface Invoices window

Payables Integration
Interfacing Module Projects Assets Cash Management Inventory Data Transferred Data Transfer Direction Project expenses (in AP invoice) Out Asset additions Out Payment reconciliation with bank Bi statement Intrastat statistics. From the Invoices Out window, you can access the Oracle Inventory Movement Statistics window Supplier info, Invoice matching Bi Lease obligations Bi Invoice, Payment Expense Report Bi In

Purchasing Property Manger iSupplier Portal Self-Service Expenses

Payment Document
E.g. cheque book or electronic payment A bank account has got multiple PDs (only internal bank accounts)

24 The attributes of a PD are as follows: Disbursement Type e.g. Computer Generated (can be used to pay only Quick Payment), Recorded (can be used to pay only Quick Payment), Combined (can be used to pay both Quick and manual Payments) Payment Format. It defines Payment Method (i.e. Check/Electronic/Wire/Clearing) Position of Remittance Advice (Before/After cheque, or Separate from check) Build and Format programs Example: For Internal Bank Account X Payment Document PD1 PD2 PD3 Disbursement Type Combined Computer Generated Recorded Payment Format Check_USD ECS ACH Check_Manual Payment Format.Payment Method Check Electronic Check Document Range 101-200 201-350 351-400 No

Each bank account can be associated with multiple Payables payment documents OR multiple Receivables payment methods, but not both.

Payments
Payment must be against invoice(s), and for a Supplier site. The different types of Payment are as follows: Single payment Quick payment Computer generated payment against selected invoices. Need to run pay cycle. Manual payment Cannot format or print such payments Refund Negative payment. Through Pay Batch (which is a form of Quick Payment) Payment : Scheduled Payment = m:n Even paid invoices may be adjusted. Scheduled payment may be recalculated, depending upon Profile Option. You can make Quick/Manual payments in two ways: Validate invoice Pay in full Enter payment Adjust against invoice You will not be able to make manual payment if Supplier/Supplier Site.Payment Method = EFT or other Electronic OR Invoice.Payment Method = Electronic For any type of payment, you need to Create Accounting For Pay Batch: Confirm Create Accounting For Quick Payment, Format and Create Accounting may be performed independent of each other. If Invoice Schedule.Payment Method = Check, that invoice schedule can be paid only through a Payment Document for which Payment Method = Check. Similarly for Electronic etc.

25 Thus the type of payment is enforced at 2 levels: Pay Document.Payment Format.Payment Method and Invoice Schedule. Payment Method

Refunds
Refund can be applied to any combination of invoices and memos, as long as they have a negative balance. Dr Cash Cr AP Only category of payment that is not associated with a Payment Document. Another way to handle Refunds: Set up Supplier as Customer too Enter Receipt in AR (Dr Cash Cr Unapplied) Enter invoice in AP (Dr Expense Cr AP). Make sure that the Unapplied and Expense accounts are the same. How to handle Refund for Prepayment? Enter Prepayment Pay Prepayment Apply invoice to Prepayment Apply debit memo to invoice Enter Refund and adjust against debit memo

Payment Batch
A Payment Batch is defined under a Payment Document. PB is run according to Pay Through Date, which can be either Due Date or Discount Date, Depending upon the flag Pay Basis defined at Payables Options. Payment Date is also mandatory. There are other optional criteria too e.g. Pay Group. The steps in the Pay Batch are as follows: Build payment The application selects invoices based on pay batch criteria. It then builds payments out of selected invoices. After the payments get built, you can add/delete invoices or prevent payment to a Supplier. After this, you need to resubmit the build program. This facility will not be available once the payment gets formatted The Preliminary Payment Register report gets generated at this point. Format payment This step calls the Payment Document.Payment Format. Format Payment program. It creates check layouts and EFT file formats. The formatted payments get stored in AP output directory. Print checks Valid only if Payment Document.Format Type = Check. If Electronic, the output file is delivered to the bank. Confirm Pay Batch On being confirmed, the Payment Document gets released. Check and invoice payment records get added. Post confirmation, you need to mark the printing status of each check. The following are the possible statuses that may be marked: OK. The check status becomes Negotiable. Spoiled. The check status becomes Spoiled. Setup. The check can be reused. Skipped. The check can be reused. PB status: New Built Formatted Confirmed Final Payment Register Register of checks generated for the PB. Preliminary Register can be printed any time between building and confirming a PB.

26 Invoice needs to be paid in same currency, or one with a fixed rate relationship. If for the Payment Document.Payment Format, Remittance Option is set to None, you may want to run Print Separate Remittance Advice too while formatting. For electronic payments, the Transmit Payment File program transmits the payment file generated to the companys bank (Disbursement Bank). It then sends a transmission status email notification to the designated user specified in the Bank Transmissions form.

Stopping/Voiding Payment
To stop the payment, take the action Initiate Stop. Release Stop resets the invoice status to Negotiable. When you void a payment, the check status becomes Voided. Invoice payment records get added with negative amount. Stop and Void payments are under Payment Actions. The other permissible actions for a payment are Create Accounting and Print Remittance Advice. In R12, this feature is available in the Payments tab

Payment Accounting
Payment Accounting depends upon the flags Account on Issue and Account on Clearing that are set at Payables Options Payments may be reconciled with bank statements, depending upon the above flags. Account on Clearing Y On Issue payment) (i.e. unreconciled On Clearing Management) (in Cash

Account on Issue Y

Dr AP 100 Cr Cash Clearing 100

Y N

N Y

Dr AP 100 Cr Cash Clearing 100

Status = Reconciled Dr Cash Clearing 100 Dr Bank Charges 5 De Bank Errors 2 Cr Cash 107 Manually reconcile. Status Reconciled Unaccounted Dr AP 100 Dr Bank Charges 5 De Bank Errors 2 Cr Cash 107

Realized gain/loss may similarly be accounted on Issue/Clearing, depending upon Payables Options flag.

Future Dated Payment


FDP is an 11i feature. It has been replaced by Bills Payables in R12. FDP instructs the companys bank to disburse funds to the Suppliers bank on or after the Maturity Date. Pre-requisite: Payment Document must be FDP enabled.

27 To pay the invoice in a payment batch or as a Quick payment in the Payment Batches Summary or the Payments Summary, choose a future dated payment document, and enter a Maturity Date. Payables will then automatically create the future dated payment. Update Matured Future Payment Status program updates the status of those FDPs, whose Maturity Date is on or before System Date, from Issued to Negotiable. Dr FDP A/C Cr Cash Clearing A/C

Integration with Projects


In AP, enter Supplier invoice (against Project-Task-Expense Item) Capitalize the asset costs to PA Interface the asset costs to FA

Supplier in R12
Create Supplier Create Supplier Address Create Site and map to address Supplier Address Site OU The attributes of Supplier Site are Ship-to-Location, Bill-to-Location, etc Every Site-OU mapping has got a Usage e.g. Purchasing, Pay, Primary Pay, RFQ Only, etc Supplier Bank Supplier (Trading Partner) Bank + Branch Bank Account

Payment Processing in R12


The mandatory fields for a standalone payment are as follows: Trading Partner, Supplier Nbr & Site, Payment Date, Bank Account, Payment Currency, Payment Method, Payment Process Profile, Payment Amount

New Payment Terminology in R12 Document Payable: A document to be paid by the deploying company (Payer). It may represent, for example, a Payables invoice or a scheduled payment. Pay Run/Payment Process Request: A pay run is a broad term, which describes the process by which a group of invoices is selected and processed for payment. It is roughly equivalent to the 11i concept of a payment batch. The term Pay Run is often changed interchangeably with the term PPR. A PPR is technically a request created by a source product for Oracle Payments payment services. The PPR, which originates in the source product during the invoice selection process, contains one or more documents payable to be paid. During the payment process, the documents payable in the PPR are built into payments. Payment Instruction: A PI is a collection of payments, along with aggregate payment information, that is formatted. Depending on the setup, a PI may be converted into a file to be

28 printed onto checks or into a payment file that is transmitted to a payment system for further processing a disbursement. Payment Process Profile: A PPP is a blueprint assigned to documents payable, which specifies all the rules to create, process, disburse, format and transmit payments. PPPs including specifications for PI formatting and transmission. PPPs contain the following information: PI formatting information Transmission information Payment grouping Payment limits Payment sorting details The key attributes of a PPP are as follows: Processing Profile (mand) {Printed, Electronic, payment Card) Payment Format (mand) Payment Completion Point (e.g. when the Payment is built/Payment Instruction created or formatted) Max documents per payment Usage Rules. Determine when the PPP can be assigned for use on docs. Rules e.g. PM (All/Specific), Int Bank A/C (All/Specific), 1st Party OU (All/Specific),Currency (All/Specific), Payment Instruction Creation rules [Payment grouping options that let you specify how PIs should be created when this PPP is used. For example, if you choose First Party Organization, only payments for the same organization will be grouped into a single PI. Any combination of the following may be used: 1st Party Organization, 1st party LE, Internal bank Account, payment Currency, Payment Reason, Payment Payment limits Total amount, Number of payments Sorting logic of payments i.e. whether according to Payee Bank branch, Payee Name, etc Format for separate Remittance Advice. Note: The format and document in PPP used in PPR should match with what is set up for the internal bank account. Otherwise invoices will not be selected in the PPR. Payment Format. A set of rules that determine how a PI or settlement batch is converted into a payment batch, readable by a payment system. PFs are registered and maintained in Oracle XML Publisher. Every PF belongs to a Publisher template. A PF has one or more pre-defined and/or user defined validations. Payment Method: A payment attribute on a document payable. The PM indicates the medium by which the deploying company (first party payer) makes a payment to the supplier (third party payee). Examples of PMs are checks printed in-house by the payer, checks outsourced to the bank for printing, and wires, Electronic (EFT, EDI or XML payment to Suppliers bank). The attributes of a PM are: Usage (any or all of AP, AR, CE, Loans, Student Systems), Automatically attach PM to all Payees (Yes, No)

29 Multiple validations (which may be either pre- or user-defined) may be mapped to the PM. These validations are run on invoices, payments, PIs.

Payment Format: Required for PI or Remittance Advice. Its attributes are: Data Extract (seeded), XML Publisher Template (use seeded). Multiple validations (which may be either preor user-defined) may be mapped to the PF. In case of Electronic PIs, the format is as required by FIs. Payment Method Defaulting Rule For defaulting PMs on to Documents Payable There is a m:n cardinality between a Rule and a PM You may indicate a Rule to be used in AP, AR, CE, etc The attributes of a PM are: First Party LE (All/Specific) First Party OU (All/Specific) Other conditions e.g. Currency, Payee Location Example: Priority 1 2 3 Rule Name Rule1 Rule2 Rule3 Rule Details LE = BD, OU = GSM, Curr = All LE = All, OU = Infra, Curr = INR LE = All, OU = Infra, Curr = BDT Payment Method PM1 PM2 PM3

Suppose there is an invoice for LE = BD, OU = Infra, Curr = BDT. In this case, Rule 1 and Rule 2 are not applicable to the invoice but Rule 3 is. Hence Rule 3 will be defaulted on to the invoice. Processing Options of the Pay Run The following are the steps of the Pay Run i.e. Payment Process Request (PPR): 1. Initiate PPR. Mandatory attributes of the PPR are: Pay Thru Date, payment Date, Payment Exchange Rate Type 2. Select Scheduled Payment (i.e. invoices) a. As a result of this step, invoices are grouped into a PPR. b. On selection, the invoices are locked to prevent other pay runs from selecting the same invoices. c. You can stop for review after this step. 3. Create Proposed Payment. a. The Build Payments program validates the invoices, groups them into payments, and validates those payments. i. Documents are validated using Payment Method based validations and then Payment Format based validations. In case of success, the validations are grouped into proposed payments. If not validated, the action to be taken is based upon the choice indicated at the PPR.

30 b. The criteria for grouping invoices into the same Payment are: Same PPP, Payment Method, Payment Format, PPP.Grouping Rules. c. You can stop for review after this step. d. Also you can remove payment or remove invoice under payment after this step. 4. Create and format Payment Instructions. a. A PI is a group of payments that is created from one or more PPRs. This information is formatted and, depending, on your setup, is converted to a payment file that is either printed onto in-house checks, or transmitted to a FI or payment system for further processing and disbursement. b. Grouping Rules: Depending upon setup grouping rules, payments in different PPRs can be built into a single PI. Grouping Rules are specified in the Payment Groups region of the Create PPP page. c. May be automatically initiated or run through SRS, depending upon the option chosen in the PPR template. d. To format PIs, the application uses XML Publisher formatting templates. There are both seeded and user configured formatting templates. 5. A) Processing Type is Electronic. In this case, depending upon flag at PPP, the payment may be automatically transmitted. If not, needs to me manually transmitted in the PI page B) Processing Type is Printed. In this case, if PPP. Send to Printer = Y, the PI is automatically printed into checks. If not, manually print the PI in the PI page. Payment Completion A payment is considered Complete as follows: 1) Electronic: Depends upon PPP.Payment Completion Point. The options are: Payment Built, PI Created, PI Formatted, PI Transmitted, Manual Setting only. Assuming manual setup is enabled, you may mark the payment complete under the Payment Administrator responsibility (Funds Disbursement Process Home Page), with any of the following statuses: Formatted, Formatted Ready for Transmission, Transmission Failed. On completion, the PI can no longer be terminated. If there are any problems with the payments, they must be voided. a. Only after a payment is marked Complete, the source product can perform any accounting action. b. You must mark all payments in a PI as Complete. Attributes of the Payment Process Request Template Suppose Nbr of Pay From Days = 4, Additional Pay Thru Days = 7. In that case, if pay run is 1-May, invoices will be selected whose due dates fall within (1+4)= 5-May and (5+7) = 12May Other Scheduled Payment Selection Criteria e.g. LEs (All/Specific), OUs (All/Specific), Payment Currency (All/Specific), Payment Attributes e.g. Disbursement Bank Account, Payables Document, , Payment Process Profile, payment Exchange Rate Type (mandatory) Process Automation (e.g. whether to stop the process for review after Scheduled Payment selection, or after creation of proposed payments, or whether to Create PI on completion of PPR or wait for SRS

31 Validation Failure Results Rejection criteria of documents and payments

Bills Payable
BP instructs companys bank to disburse funds to Suppliers bank on a specific date, known as Maturity Date Setup Payment Method Set Use Payment Method to issue BP = Yes. Also, even though payments created with a BP PM will have a maturity date that is based on the earliest available discount or due date when the payment is created, you can optionally override this calculation by entering a value for the number of days in the Maturity Date Override field at the PM (Maturity Date = System Date + Override). This is further overridable at the Payment Also in the PPP, if you set BP = Y (under Grouping Rules), only BPs will be grouped into a single PI. On or after the Maturity Date, you can set the status of the BP from Issued to Negotiable. This can be done manually or by running the Update Mature Bills Payable Status program.

Create Accounting and Posting to GL


The following are the events that would cause accounting to be generated when the Payables Accounting process is run:

Validate an invoice Pay an invoice Receive (for inventory items. For expense items, this is valid only if Accrue at Receipt at the Purchasing Options is Yes) Clear a payment with Cash Management.

While submitting the AP Transfer to GL process, there are parameters that require input and each is important to the results received from the posting. Post Thru Date: The GL_DATE attached to an invoice distribution or payment determines in which accounting period the transaction will be posted. All viable non-posted transactions having a GL_DATE less than or equal to the date entered in this field will be selected for posting. Posting in Detail or Summary: This parameter determines the level of detail information recorded in the general ledger. Detail: Detailed posting implies that every invoice or payment distribution will create a unique GL journal entry. For example, 2 invoices with distributions charged to the same expense account will create 2 journal entries, each with a distinct debit and credit. Summary: Summary posting groups transactions with similar accounting flexfield information together, and creates a single GL journal for each grouping. Debits and credits made to the same accounting flexfield are grouped separately, they are not summed together and net out.

32

Posting with Audit: Audit provides the information necessary to uniquely identify the AP transaction that created a GL accounting entry. (Information such as Invoice Number, Supplier Name, Check Number, etc.) Audit works with the detail/summary option to provide the information you desire to see in the GL. You must post in audit in order to utilize the following features: Posting in detail Zooming from GL to AP for transaction detail Running the Posted Payment and Invoice reports

Audit is required in order to post in detail. If you request detail information, but do not have audit selected, you will not see detail, but summary information in the GL_INTERFACE table. There are different types of accounting transactions that can be inserted into the GL_INTERFACE table, and for each type, you can determine whether to request audit or not. Cash and Expense Transactions: All transactions that affect a cash or expense account require Audit information. You can not change the default for these items. Discount, Realized Gain/Loss, and Cash Clearing (future payment) transactions: You have the option to select Audit or No Audit. Liability transactions: You have the option to select Audit, No Audit or partial audit. Partial audit summarizes the liability transactions per invoice or payment, instead of for the entire posting batch. This provides enough detail to know which invoice or payment a transaction came from, but the individual distribution detail for that item is summarized. Submit Journal Import When running the AP Transfer to GL process, the Journal Import process can be initiated from either the GL system or the AP system. If the option "Submit Journal Import" is equal to YES, once the AP transfer is complete the Journal Import program is automatically executed. If "Submit Journal Import" is equal to NO, then you manually submit the Journal Import process through the GL. When submitting the process manually, there are 2 additional options that must be selected: Source and GROUP_ID. The source and GROUP_ID are used to uniquely identify which transactions in the GL_INTERFACE table you are requesting to import. For AP, the source will always be equal to Payables. The GROUP_ID will be unique for each posting batch that is created. A unique GROUP_ID is generated during the AP transfer process, and it identifies every transaction that belongs to the posting batch. The purpose of the journal import is to extract the accounting transactions and audit information from the GL_INTERFACE table and populate the appropriate GL tables. The transaction information in the GL_INTERFACE table will generate the actual accounting transactions in the

33 GL journal tables (GL_BATCHES, GL_HEADERS and GL_LINES). During import, the audit information is removed from the GL_INTERFACE table and inserted into the GL_IMPORT_REFERENCES table. This table must be populated in order to produce the Posted Payment and Posted Invoice reports. This data is also used to zoom from a GL journal line to the originating AP transaction. The Audit information is the ONLY stored data link between the GL and AP transactions. If you do not post in audit, you can not perform these functions. When submitting the Journal Import process from the GL, there is an option to import descriptive flexfields. The AP system does not currently send the information required to populate the descriptive flexfields. Although this option can be used for importing from other applications, it does NOT work for AP journals.

Integration of Payables with Other ERP Modules

C:\Users\ Adm inistrator\Desktop\Oracle\Metalink downloads\AP\IntegrationPayables.docx

AP Period Closing Activities


Month-end closing within the Oracle Payables system. is a simple process. You navigate to the close period form, select close, commit, and if all is well, your period will close and balance. Its that little phrase if all is well that introduces the bulk of the work required for the month end closing. The closing process will be divided into 5 main steps. Pre-post work Posting Reporting Balancing Closing

34

A. Pre-Post Work
Before you can post to the GL, you want to review both your invoice and payment transactions to insure that they are ready to post. Insure invoices are ready to post: An invoice must be approved and/or have no posting holds in order to be selected for posting. To insure that your invoices are ready to post, you should run autoapproval and review the hold reports. Oracle provides 3 hold reports for this purpose. If an invoice appears on any of these reports, you either need to adjust the invoice or manually remove the hold. Invoice Hold Report - displays all held invoices. Posting Hold Report - only displays invoices with holds that prevent posting. Matching Hold Report - only displays invoices with matching holds. Insure Payments are made: Confirm or cancel all pay runs (R12) or pay batches (11i). Update all Bills Payable (R12) or Future Dated Payments (11i) A. Posting Run Payables Transfer to General Ledger for the existing period. (Exception transactions for posting can be an inactive accounting flexfield value, a GL_DATE in an un-opened GL period, exchange rate missing, etc.) When an invoice or payment encounters an exception, the distribution containing the exception will not post, yet will not prevent the other distributions from posting. For example, an invoice with 2 distributions can have one distribution that posted and one that encountered an exception. If you query the invoice, the status will show as partially posted. After the process is complete, the AP Journal reports are generated to display the results of the

35 posting selection. These reports are very important and should be saved. They are generated directly from the posting process and can not be rerun at a latter date. Accounts Payable Journal Entry Audit Report: This report lists the details of the accounting transactions that have been inserted into the GL_INTERFACE table. It displays the AP transaction, its corresponding debits and credits, the GL accounts affected, and more. Accounts Payable Journal Entry Exception Report: This report displays the transactions that encountered an exception during the posting process. Each transaction includes an exception code that explains why it was prevented from posting. All transactions appearing on this report will require some change in order to be selected for posting the next time you run the AP transfer process. A. Reporting Once the posting process is complete, you are ready to run some key reports to insure that both your Payables sub-ledger and the General Ledger are in balance. Unposted Invoice Sweep Report: This report informs you about un-posted invoices and payments in the current or previous open periods. If un-posted transactions exist, you must decide if you want to post them in the current period or sweep them (move them) to the next open period. The parameter, "Report Only", determines if the unposted transactions are simply displayed or displayed AND SWEPT to the next open period. When a transaction is swept, its GL_DATE is changed to the first day of the next open period. Accounts Payable Trial Balance Report: This report displays the individual liability for every supplier that has an open balance. The report is divided and summed by liability account, and should balance to the respective AP Liability account in the general ledger. Only invoices and payments that have been POSTED in AP will display on this report. Posted Invoice Report, Posted Payment Report: These reports display the invoices or payments that have been posted to the general ledger in a given date range. In order for a transaction to appear on these reports, it must have been posted in audit in AP, and imported into the general ledger. Expense Distribution Report, Payment Distribution Report: These reports display the accounting transactions that will be created when you post your transactions. They can be run before or after you post, as they analyze each AP transaction and display what accounting transactions will be created during the posting process. They show accounting detail that you can not see by viewing a transaction online. Journal with GL Details Report Transaction Reconciliation Report: These reports are used to review details of transactions posted from AP and imported into the GL. The report is based on data in the GL_IMPORT_REFERENCES table, which is populated when you post in Audit. If you have not posted in Audit, this information will not be available. A. Balancing The reports described above will be used in the balancing process. To determine if your system is in balance, you need to insure that the amount reported in AP matches the amount reported in the GL. In addition, there are times when you want to see that the AP system is in balance with itself. Balancing AP Every transaction that is posted from AP to the GL is reflected in the Accounts Payable Trial Balance report. If you want to test the data on this report against the transactions entered for a supplier, you can spot check individual suppliers. View the outstanding balance for the individual supplier via the invoice inquiry form and compare it to the data on the trial balance report. The

36 on-line balance inquiry includes all transactions, unlike the trail balance report that only includes posted transactions. Therefore, the on-line supplier balance should match the data reported on the trial balance report, +/- any non-posted transactions.

Balancing AP to the GL To balance the AP and GL systems together, the AP Trial Balance report should agree with the GL liability accounts and the posting reports. GL posted transactions and AP trial balance: Utilizing the trial balance report and the posting reports, you can insure that the transactions imported into the GL system agree with those entered and posted in the AP system. Although the posting reports are run from the AP menu, they are based on data stored in the GL system (GL_IMPORT_REFERENCES table). If you did not post in audit or are using Cash based accounting, you will not be able to perform this balancing process. To balance, you will need this month's and last months AP Trial Balance Report, and this months posting reports.

Balance GL liability account to the trial balance: Verify that the GL liability accounts agree with the data reported on the AP trial balance report. Balance GL batch to the AP posting batch: When you post and import transactions from AP into the GL system, a unique GL batch is created. You can balance a GL batch against the AP Journal Entry Audit report that was generated during the AP transfer process. If your set of books allows intercompany accounting, the GL batch totals may be higher than the totals listed on the AP Journal Entry Audit report. When posting a GL batch, if transactions do not balance across balancing segments, the GL system will automatically create the entries necessary to balance the amounts in each segment. These transactions will be displayed in the posted GL batch, but will not be reflected in the AP system.

A. Closing the Period

37 When you are comfortable that your system is in balance, you are ready to close the period. To open or close a period in the Payables system, use the period control form. Although the AP periods mirror those defined in your GL Set of Books, they are controlled independently. Both the AP and GL systems are required to open and close their own periods. When attempting to close an AP period, if un-posted transactions exist, a message will be displayed and the period will not be closed. At that point, you need to repeat the pre-post steps mentioned above in order to identify and adjust, or sweep the un-posted transactions. You can re-open a closed period in AP as long as it is not finally closed, and the corresponding GL period is not closed. Once a final close has been done, the period can never be reopened. It is recommended that you final close a period only if it is from a prior year.

Document Sequencing
134120.1

Defaulting Hierarchy
Liability, prepayment, FDP accounts: Financial Options Supplier Site Cash, Cash Clearing account: Bank account (for R12, at both the following levels: Account Control, OU Access); for 11i: Bank Account Bank account +OU FDP Account: Bank Account + OU Expense AP Accrual Account: Purchasing Options Invoice Match Action: Payables System Setup Supplier Supplier Site PO Shipment Realized Gain, Realized Loss accounts: Bank account + OU Hold from payment (all invoices, unmatched invoices, unvalidated invoices): Supplier Supplier Site Invoice Amount Limit: Supplier Site Allow WHT: Payables Option Supplier Supplier Numbering: Payables System Setup Invoice Match Option (PO, Receipt): Payables System Setup Invoice Invoice Currency: Payables System Setup Payables Options Supplier Site Invoice Terms Date Basis: Payables System SetupPayables Options Supplier Site GL Date Basis {Invoice Date, System Date, Invoice Received Date}: Payables Options Invoice Batch Invoice Header Invoice Distribution Pay Date Basis: Payables System SetupPayables Options Supplier Site Pay Terms: Payables System SetupPayables Options Supplier Site Always Take Discount: Payables System Setup Supplier Site Use Multiple Currency (i.e. whether you want to pay invoices in currencies other than functional currency): Payables Options Realized Gain and Loss accounts Payables Options Allow adjustment to paid invoices - Payables Options Recalculate scheduled payment - Payables Options Allow final matching - Payables Options Create debit memo from RTS transaction Supplier Site Invoice tolerance Supplier Site

38 Payment currency - Supplier Site Invoice Default Payment Method: Supplier Site Invoice Scheduled Payment Payment Pay Alone: Supplier Site