Oracle Receivables

Contents
Customer..............................................................................................................................4 Merging Customers ..............................................................................................................................................5 Transactions ..............................................................................................................................................5 Transaction Line..............................................................................................................5 Invoice Transaction Flow................................................................................................6 Overview of Corrections..................................................................................................7 Lifecycle of transaction....................................................................................................7 Credit Memo....................................................................................................................8 Recurring Invoices...........................................................................................................9 AR Tax.................................................................................................................................9 Adjustment.........................................................................................................................10 Invoicing with Rules..........................................................................................................11 Invoicing Rules..............................................................................................................11 Accounting Rules...........................................................................................................11 Accounting Entries.........................................................................................................12 Accounting Rules Types................................................................................................12 Commitment ............................................................................................................................................13 Commitment accounting ........................................................................................................................................13 AutoAccounting ................................................................................................................14 AME Credit Request Workflow .......................................................................................14 AutoInvoice........................................................................................................................14 Grouping Rules..............................................................................................................15 Transaction Sources for AutoInvoice............................................................................16 What Occurs during AutoInvoice..................................................................................16 Document Linkages.......................................................................................................16 Credit Memo Considerations for AutoInvoice..............................................................17 Receipt Class and Receipt Method....................................................................................17 Receipt...............................................................................................................................17 Receipt Reversal............................................................................................................18 Receivables Application....................................................................................................19 How do you apply payments to unrelated customers' invoices?...................................20 What do you do with invoices that have credit balances?.............................................20 Chargeback........................................................................................................................20 Accounting.....................................................................................................................21 Open Amount Calculations............................................................................................21 Lockbox and QuickCash....................................................................................................21 AutoCash........................................................................................................................23 Automatic Receipt.............................................................................................................23 Collection...........................................................................................................................25 Dunning Letters.................................................................................................................25

Statements..........................................................................................................................26 Cross Currency Receipts....................................................................................................26 AR Open Interfaces............................................................................................................27 GL Transfer .......................................................................................................................27 Exclusions..........................................................................................................................28

Customer
Customer model (11i): Single source of truth. Used by Financials, Customer Care.

Party: Organization or person that can enter into business. It exists separately from any business relationship that it enters into with another party. There are 4 types: Organization, Person, Group (to which other party(s) belong), Party Relationship. HZ_PARTIES Customer: Entity with whom I have a selling relationship. In AR, a customer is modeled as a party. Customer account: Terms and conditions of doing business are defined here. Transactions are entered against a customer account. HZ_CUST_ACCOUNTS Customer account site: Customer account site is configured as a location (HZ_LOCATION) Customer account site use: Seeded site uses: Bill-To, Ship-To, Statement, Dunning. The user can add more.

Example Party Cust A/C Cust A/C Site Commercial A/C Noida Pune Vision Enterprises Reseller A/C

Cust A/C Site Uses

Bill-To, Ship-To, Dunning

Ship-To, Statement, Marketing

In the 11i Customer model, tables begin with HZ. Backward compatibility is achieved by recasting AR tables (e.g. AR_CUST) as views on underlying HZ tables.

HZ_Parties HZ_Cust_Accounts HZ_Cust_Acct_Sites_All HZ_Cust_Site_Uses_All HZ_Party_Sites HZ_Locations Customer Profile Class: Contains credit information e.g. credit limit, statement, dunning Define Customer Profile Class Assign to Customer or Customer Bill-to-address as default values Parent-Child Relationship: If System Options. Allow Payment of Unrelated Invoices = Y, there can be parent-child relationship between customers w.r.t. payment of invoices. Configured as separate Bill-To and Paying Customers on the Transactions form. Apply Receipt of the latter to Invoice of the former. This relationship can be either one-way or reciprocal. Customer Account Balance: Customer Account Balance = Invoice + Debit Memo + (Positive) Adjustment Credit Memo Receipt (Negative) Adjustment. The AR Balance can be seen in the Account Details screen or the Aging Reports. (The Account Details screen displays information at the level of payment schedules)

Merging Customers
Merging site uses for the same customer e.g. merge Pune Bill-To to Noida Bill-To. All activities (invoices, receipts) belonging to Pune now belong to Noida (e.g. from Pune Ship-To to Noida Ship-To) Merging different customers: All Bill-To Uses merged to target customer Bill-To Uses, All Ship-To Uses merged to target customer Ship -To Uses, etc. While merging, you may choose to delete the From Customer as well. You cannot merge two sites (whether they belong to the same or different customers) if the two sites do not have a site use common between them.

Transactions
The attributes of a Transaction are as follows: Transaction Type The attributes are Transaction Class (Invoice, DM, CM, CB, Guarantee), ARD (only for debit items), Post-to-GL, etc Transaction Source Used to default Transaction Type in transactions, and for numbering of transactions (i.e. whether automatic/manual) Transaction Date can be in any period. GL date must be in an open or a future period.

Transaction Line

Can be of type: Line, Tax (n per parent line/invoice), Freight (1 per parent line/invoice) Can be either of the following: Inventory Item, Standard Memo, Description. Standard memo is for non-inventory items. Used in AutoAccounting.

Amount is entered at the Transaction Line level Tax line is created automatically, depending upon the Tax Code of the parent. It may be created manually too. You can tinker (i.e. Standard/Exempt/Force) with tax at the Transaction Line level, depending upon the Profile Option Tax: Allow Override of Customer Exemptions, and provided the transaction is not a Chargeback. o Standard if you want tax to be calculated as per AR norms o Exempt: To force tax exemption on invoice lines Set System Options.Use Customer Exemptions = Y. Require to force tax. Similar to customers, items may also be exempted Tax Codes may be compounded, depending upon Tax Code defaulting hierarchy defined at System Options.

Invoice Transaction Flow

Underinvoice cases: Debit Memo, Adjustment Overinvoice cases: Credit Memo, on Account Credit, Adjustment, Refund The system option Allow Change to Printed Transactions determines whether you can update a transaction after it has been printed.

Overview of Corrections

Lifecycle of transaction
After entering a transaction (through or without batches), you need to complete it. On Completion, Payment Schedules are created. After completing a transaction, you may perform any of the following Activities on it: Apply Receipts Enter CM against transaction Include in Consolidated Billing Adjust transaction Post to GL You cannot update a transaction once it has an activity against it.

You can void a transaction by updating the Transaction Type provided the transaction does not have any activity against it, or not posted to GL (Transaction Type.Transaction Status becomes Void)

Credit Memo
There are 2 types of Credit Memos: On-Account Credit Memos which are created independent of a transaction. These maintain an open credit balance that is waiting to be applied to a customer's outstanding balance. Entered through the Transactions form. Transaction Type.Class = Credit Memo. Can subsequently be applied to invoices and receipts. Applied Credit Memos which are created in reference to an existing transaction. The credit amount is applied against Invoices, Debit Memos, or Commitments impacting freight as well as invoice lines. Entered in the Credit Transactions form, which is like the normal Transactions form only. Added to the DB in identical manner as any other transaction. Only difference is that the Credited Transaction is referenced in the memo header (for Applied CMs only). Depending on the amount you are crediting you have the following options (for Applied CM): Full Credit: Will credit the entire balance due for this transaction, bringing to zero the balance due for Line, Tax and Freight. Partial Credit has 2 options: o Enter the percentage or amount for: Line, Tax, Freight. You need to specify either percentage or amount, the value you did not provide will be calculated for you. o Use the Credit Lines button, and enter details for each line on how much you want to credit. If you have freight assigned at the line level, you need to use Credit Lines to credit freight amounts. Also, if you want to overapply a credit against a transaction, you can only do it by using Credit Lines. Percentages are based on the original balance of the transaction you are crediting. A credit transaction has many credit lines. Credit memos cannot be unapplied or reversed from the invoice once they have been created. Use the Credit Balance button to credit 100% of the remaining invoice value The Profile Option AR: Use Invoice Accounting for Credit Memos determines whether the credit memo uses the same GL accounts used by the invoice it is crediting, or to generate its own GL accounts from the AutoAccounting setup. This gives you the capability to post to a completely different set of GL accounts for credit memos if necessary. When applying a credit memo to a transaction, the credit memo currency must be the same as the transaction currency.

If you are crediting a transaction that has multiple installments, choose one of the following Split Term Methods: First in First Out (FIFO): This method credits the first installment first Last in First Out (LIFO): This method credits the last installment first Prorate: This method prorates the credit amount across the remaining amount of all installments If you are crediting a transaction that uses Invoicing and Accounting rules, the appropriate Rules Method must be chosen: Last In First Out (Lifo): Choose this option to back out revenue starting with the last general ledger period and reverse all prior periods until it has used up the credit memo amount Prorate: Choose this option to credit an equal percentage to all revenue distributions for this invoice. Unit: Choose this option to reverse the revenue for the number of units you specify from an original line of the invoice. You can issue refunds against On-Account Credit Memos. Query the On-Account credit memo, use the menu toolbar Actions > Applications and in Apply To column enter Refund. Accounting for Credit Memos Following is a sample of the accounting entries created for a credit memo: When the credit memo is created: Account Type Amount Revenue Tax Freight Receivables -100.00 -20.00 -10.00 -130.00

Debit 100.00 20.00 10.00

Credit

130.00

When the credit memo is applied: Account Type Receivables (of the Credit Memo) Receivables (of the Invoice)

Amount -130.00 -130.00

Debit 130.00

Credit 130.00

Recurring Invoices
May be created in the Transactions Summary or the Copy Transactions windows, using a Copy rule (e.g. Weekly, Monthly, Days, etc)

AR Tax

You can set up AR to use one of 2 basic types of tax: VAT or Sales Tax. The latter is dependent upon Location.

Value Added Tax (VAT) is imposed on the supply of goods and services paid for by the consumer, but collected at each stage of the production and distribution chain. The VAT charged on a customer invoice is called Output Tax. Any VAT paid on a vendor invoice is called Input Tax. The amount due each period can be described as follows: Amount Due = Output Tax Input Tax. Receivables provides a comprehensive solution for VAT reporting using standard and countryspecific reports. Sales tax in Receivables is based on the destination of the supply of goods or services. The calculation of sales rates is automatic, and is based on the state, county, city, and zip code of your customers address and the tax rates assigned to each of these components. You can override any tax rate through customer and product exemptions and you can compile periodic sales tax returns using the US Sales Tax Report. Both types of tax can be set up so that specific items or customers are exempt Tax defaulting hierarchy is defined at System Options Sales Tax Rate interface loads ST rate records to AR from a ST feeder system.

Adjustment

Create adjustments to increase or decrease the balance due for an invoices, debit memos, chargebacks, on-account credits, deposits, and guarantees. A Payment Schedule may have multiple Adjustments i.e. Adjustments are always against Payment Schedules. Alteration to debit items. Internal corrections or data entry error, WriteOff, etc always against a Receivable activity. Open Amount = Open Amount +/- Summation of Adjustments Set approval limit for user Try to adjust. If adjustment amount is within Approval Limit, then adjustment gets approved (Open Amount of Payment Schedule gets updated). Otherwise the adjustment goes to Pending status. Only a supervisor with suitable Approval Limit can approve it. Approval Limits are valid for the following as well: Receipt WriteOff, Credit Memo, Refund Accounting entry for positive adjustment: Dr AR Cr Adjustment (user entered Receivable activity) The CCID mapped to the Receivable Activity is defaulted during adjustment. You may override this value, depending upon the Profile Option AR: Override Adjustment Activity Account Option You can adjust during application too (e.g. invoice is $100 but customer remits $98. Instead of keeping the invoice open or charging back, you can adjust it to $98). If you create an adjustment during a receipt application and then unapply the application later, Receivables reverses the adjustment AutoAdjustment Run to automatically adjust remaining open amount of all open items. E.g. adjust all invoices with 5% open amount remaining and with due date on or before 31-May. Adjustment gets created in Pending/Approved status, depending upon Approval Limit. Similar to AutoAdjustment, there is Automatic Receipt WriteOff too. Writing off bad debt is achieved by writing down the invoice to 0.

Invoicing with Rules

You may have business or legal requirements that dictate how you can account for the revenue associated to the invoice. Perhaps you recognize the revenue in full once the invoice is paid, or for invoices associated with a service spread out over multiple months, you may need to recognize the revenue only when the service has been provided. The manner in which you control when revenue is recognized is handled by Invoicing and Accounting Rules.

Invoicing Rules
Once you associate an Invoicing rule to an invoice, you are tagging it for processing by Revenue Recognition. The Invoicing rule provided tells Revenue Recognition how you want it to create the distributions for the Receivable account. You can assign invoicing rules to invoices that you manually enter or import into Receivables through AutoInvoice. Oracle Receivables seeded 2 Invoicing Rules, you cannot create more: Bill in Advance: This rule allows you to recognize the Receivable amount at the start of the revenue recognition schedule. Bill in Arrears: This rule allows you to recognize the Receivable amount at the end of the revenue recognition schedule. Invoicing Rules are associated to an Invoice at the Header level, and is enabled only when Class = Invoice.

Accounting Rules
In the Lines of the invoice, where you provide Accounting rule, duration, rule start date information, you are telling Revenue Recognition how you want it to create the distributions for the Revenue account.

Accounting rules determine the number of periods and percentage of total revenue to record in each accounting period. You can define various accounting rules which can recognize Revenue in one or more accounting periods. Transactions entered either manually or through AutoInvoice can use Accounting Rules for as long as they are associated to an Invoicing Rule. Oracle Receivables seeds 1 Accounting Rule, you can create more as required by your business needs: Immediate: This accounting rule recognizes the entire revenue for a transaction in one accounting period. Accounting Rules are associated to an Invoice at the Line level. Once an invoice is associated to an Invoicing Rule, each of its lines needs to be associated to an Accounting Rule. If you can recognize Revenue for all of your invoice lines immediately, then there is no need to use Invoicing and Accounting Rules.

If however, you have an invoice line for which you need to spread out the recognition of Revenue across several periods, then you need to use Invoicing and Accounting Rules. For example, Invoice #123 has 3 invoice lines. Line 1 and Line 2, Revenue can be recognized immediately. Line 3, Revenue has to be spread over 3 periods. You would have to associate an Invoicing Rule at the header level. Doing this enables you to enter a value in the Accounting Rule for each line. For Line 1 and 2, you will use the seeded Accounting Rule = Immediate. For Line 3, you will use an Accounting Rule that you have previously defined, that allocates revenue across 3 periods. After the invoice is completed, you will need to run Revenue Recognition so it can create the necessary distributions. Revenue Recognition is an engine that will create GL distributions for your invoices reflecting the revenue schedule you defined. There are multiple ways to run Revenue Recognition: Revenue Recognition is run as a batch process either as a stand-alone or automatically when you invoke transfer of accounting to the General Ledger. The process will pick up all invoices with rules that have not yet been processed. For each of these invoices, it will review the Invoicing and Accounting rules associated and create the necessary GL distributions. The GL distributions it creates is how invoices in Receivables get posted to the General Ledger. Note that the presence of an Open period sandwiched between Closed periods, or the presence of islands of Closed periods surrounded by Open periods causes errors in Revenue Recognition.

Accounting Entries
Example: 3 month period, revenue of $100 p.m. Bill in Advance Month 1: Dr AR Cr Unearned Rev 300 Dr Unearned Rev Cr Rev 100 Mths 2 & 3: Dr Unearned Rev Cr Rev 100 Bill in Arrears Mths 1 & 2: Dr Unbilled AR Cr Rev 100 Month 3: Dr Unbilled AR Cr Rev 100 Dr AR Cr Unbilled AR 300

Invoicing Rule (e.g. Bill in Advance) is attached to Transaction header Accounting Rule is attached to Transaction Line. Attributes of Accounting Rule Revenue Recognition schedule e.g. 20%-30%-40%-10% Period Type e.g. Month 1st GL Date e.g. 15-Feb Define Invoicing and Accounting Rules Assign to invoices Add and complete invoice Run Revenue Recognition program All GL distributions created

Accounting Rules Types

Type: You have 4 options for Rule type

Fixed Schedule (formerly Fixed Duration), this type prorates 100% evenly across the Number of Periods you specify. Variable Schedule (formerly Variable Duration), this type allows you to later specify, during invoice data entry, the number of periods over which you want to recognize revenue. The next 2 types were introduced in 11.5.10 Family Pack G via the Patch 5684129 : Partial Period Revenue Recognition Backport Project on FP.G. Following are some term definitions: Daily Revenue Rate = Total Revenue / Total Number of Days across all periods Partial Period is when the invoice exists for only part of the period as opposed to all days within the period (see example below). Daily Revenue Rate, All Periods, this type will use a daily revenue rate to calculate the precise amount of revenue for all periods whether it is full or partial. Use accounting rules of this type to meet strict revenue accounting standards which require accurate revenue recognition on a per-day basis. Daily Revenue Rate, Partial Periods, this type is a hybrid between Fixed Schedule and Daily Revenue Rate, All Periods. It will use a daily revenue rate to calculate the precise amount of revenue for the partial periods in the schedule, then prorate the revenue evenly across the full periods.

Commitment
A Commitment can be either a Deposit or a Guarantee Deposit to record customer prepayment i.e. when the Customer agrees to pay a deposit for goods that they have not ordered yet. Guarantee Contractual agreement with the customer to conduct business over a specified period of time. Enter like any other transaction but with Transaction Class as Deposit/Guarantee

Commitment accounting
Event Enter Deposit Commitment ($1000) Enter payment against DC ($1000) Apply invoice ($1600) against DC Dr AR (Deposit) Cash AR Unearned Revenue Revenue Cr Unearned Revenue AR (Deposit) Amount 1000 1000 300 1000 1300

Guarantee accounting: On entering Guarantee, Dr Unbilled AR Cr Unearned Revenue. Rest of the accounting is the same as in Commitment.

AutoAccounting
Default ARD for AR accounts e.g. AR, Revenue, Tax, Freight, Unbilled AR, Unearned Revenue (i.e. accounts required during debit item entry only; not credit item or Receipt entry) Autoaccounting is called when creating transactions manually or through AutoInvoice. It is used for Invoices, Credit Memos and Debit Memos. Can be overridden at the transaction. Can also be overridden by accounting rules as defined in SLA. Example AR account Table Segment 1 Bill To site Segment 2 Salesperson Segment 3 Transaction Type Segment 3 Transaction Type Segment 4 Constant

Revenue account Table Salesperson table

Segment 1 Salesperson

Segment 2 Constant

Segment 4 Standard Item

Name Value John 05 Jane 28 Harry 13 Ravi 91 Must be defined for the corresponding Value Sets Thus if there is a transaction where John is the Salesperson, 05 will be defaulted in Segment 2 of AR account. Other segments will be populated based upon similar tables (or a Constant value from the Value Set, if you so choose). Once all the segments of your accounting flexfield have been derived based on your Autoaccounting setup, it is then validated by Autoaccounting to ensure it is a valid code combination.

AME Credit Request Workflow

Pre-defined workflow process that routes a CM request for approval. The workflow is initiated from iReceivables or Collections. Uses AME.

AutoInvoice
AutoInvoice is a powerful and flexible tool, used to import and validate transaction data from external financial systems or other modules of Oracle Applications. Users can

create Invoices, debit memos, credit memos, and on-account credits in Oracle Receivables using AutoInvoice.

The feeder program extracts the data from source systems (e.g. Order Management, Project Billing, Service, Property Management, Lease Management, Loans, external billing systems) and populates the same into the interface tables. The feeder program is an interface program for the Oracle modules, and custom feeder program (e.g. SQL Loader) in the case of external billing systems. When the AutoInvoice Master Program and Import Program are run, the data passes through certain validation processes and finally populates the tables of the Oracle Receivables module. You can view and correct failed lines in the Interface Lines and AutoInvoice Errors windows. Interface Lines window displays all records in the interface tables that failed validation. AutoInvoice Errors window displays any error associated with each failed record. Data correction tasks can be done by business users. RA_INTERFACE_LINES_ALL: Contains information related to all transactions to be processed by AutoInvoice e.g. Invoice, DM, CM, On Account Credits. A record can be a parent record: Line, Header, Freight, Charges, or a child record: Tax or Line level freight. Child record is linked to the parent record using the Link_to_Transaction FF. RA_INTERFACE_DISTRIBUTIONS_ALL: You can choose to pass some or all account information to AutoInvoice. Any accounts that are not passed will be derived using AutoAccounting. Records in this table are linked to records in the Interface lines table using the Transaction FF.

Grouping Rules
Grouping Rules tell AutoInvoice how you wan to group records in the interface tables into an invoice or a memo. Grouping Rule specifies attributes that must be identical for lines to appear on the same transaction (e.g. Currency, Bill-To-Customer, Sales Order) A Grouping Rule is specific to a particular Transaction Class (e.g. invoice, DM, CM)

GR has both mandatory (e.g. Bill-To-Address, Currency, Primary Salesperson, GL Date) and optional (e.g. Accounting Rules, Sale Ordcer, Tax Rate Code) attributes. AutoInvoice uses a hierarchy to determine which Grouping Rule to use (System Options Customer Profile at Customer Customer Profile at Customer Site Transaction Sources) A GR may be associated with no or one Line Ordering Rule. The latter determines how to order transaction lines (identified by the GR) within the transaction (same attributes as in GR)

Transaction Sources for AutoInvoice

Type = Imported Transaction Source provides the following options for AutoInvoice In case tax rate of the imported transaction is not matching with the tax rate of the tax code, AR either rejects the transaction or adjusts the tax rate properly E.g. GR decides that 3 lines are to be grouped into I invoice. However, 1 of these lines is not valid. Then you may choose to reject the entire invoice, or create the invoice excluding the invoice line. If the transaction date is in a closed period, you can adjust the date to the first GL date of the next open or future period, or you can reject the transaction.

What Occurs during AutoInvoice SQL Loader program populates the 3 interface tables with line, sales credit and

accounting information. BFB payment terms are validated. Lines are grouped and ordered by the grouping and line ordering rules defined. Contingencies are assigned to lines. LEs are assigned to transactions. Because each transaction can belong to only 1 LE, when multiple LEs exist, the system optionally defaults an LE from the Transaction Type or the Transaction Batch Source, if defined. If LE defaults are not defined, then the user must enter the LE manually. Tax is calculated by E-Business Tax. GL date is determined by the accounting rules or if rules are not used, from the Ship or the SO Date. GL accounts are assigned using AutoAccounting, where necessary except where accounting is provided on the transaction. Tax, freight, commitments, and CMs are linked to Transaction Lines based open Ref ID or Ref Flexfield. All transactions are batched by Batch Source Name and Request ID. Validated lines create the transactions. Error lines remain in the interface table for corrections.

Document Linkages
You can link a CM to an invoice by populating the CM Line.Reference Transaction FF (CM Line.Ref_Line_Attrib 1-15) with the Invoice Line.Line Transaction FF (Interface_Line_Attrib_1-15)

Invoice to Commitment: Invoice Line.Reference Transaction FF = Commitment Line.Line Transaction FF Tax/Freight to Invoice: Tax/Freight Line.Link_To_Tranaction FF = Invoice Line.Line Transaction FF All these FFs map to columns e.g. Line Transaction FF is Interface__Line_Attrib 1-15

Credit Memo Considerations for AutoInvoice

When you create a CM via AutoInvoice, AR submits the request to AP for automated refund, which in turn submits the request to Payments for fund disbursement. To view the status of your refund in the AP Workbench, you can choose the Refund Status button from the Receipt Application window. In the System Options form, in the tab Tax Defaults and Rules, there is a checkbox Calculate Tax on Credit Memo during Autoinvoice. If this is: Checked, the tax engine is called and calculates the tax on the credit memo as an independent transaction without cross validating the invoice it is crediting. This behavior is similar to clicking on the Credit Lines button during manual credit memo data entry. By doing so, the tax engine uses the tax code of each line in the credit memo to calculate the tax. Unchecked, Receivables will make the proration based on the taxes calculated on the invoice being credited. This behavior is similar to putting a % or amount in the Credit Transactions data entry form without going to the credit lines. In this case the tax is prorated from the taxes of the invoice being credited and is not calculated by tax engine.

Receipt Class and Receipt Method

Receipt Class Receipt Method Remittance Bank Account The attributes of a Receipt Class are: o Creation Method (Manual, Automatic) o Clearance Method (Directly, By Automatic Clearing, By Matching) Receipt is entered against Receipt Method Only those Remittance Bank Accounts that are mapped to the Receipt Method can be assigned to the Receipt. One of these bank accounts needs to be designated as Primary, for defaulting on the Receipt o Receipt ARD are defined at Bank Account

Receipt
A Receipt can be of the following types: o Cash: Can be Applied, On Account or Unidentified (i.e. customer not identified): whether to allow discount after Discount Date o Miscellaneous - no customer only GL distributions i.e. cash received in respect to revenue that has not been invoiced e.g. investment income, bank interest. Miscellaneous Receipt is entered against an Activity, which provides the default GL distribution. Remittance Bank Account is mandatory on a Receipt

On adding a Receipt, the following records get added: Cash Receipt, Payment Schedule (only 1 record, unlike Transactions), Receivable Application (Status = UNAPP), Cash Receipt History (Status = Remitted) You can optionally have Receipt Batches (Regular/Quick/Automatic). Receipt Source indicates whether such batches are numbered manually or automatically. You can reverse a Receipt. Types of Receipt reversal: Standard (re-opens applied invoices), DM reversal (creates DM in lieu of re-opening applied invoices) AR does not automatically number manual receipts. However, document sequencing can be activated for manual receipts. Document sequence numbers are unique numbers that can be assigned to receipts created in Receivables. Document sequencing is an optional feature within Receivables that can be activated using a profile option. This will generate the document number for a manual receipt, but the receipt number itself needs to be entered manually as the document sequence is not copied to the receipt number. The exception to this is that if you are using automatic receipts, you must use document sequencing to sequence the automatically generated receipts.

Receipt Reversal
Receivables lets you reverse a receipt when a customer stops payment on a receipt or if a receipt is returned from the bank for insufficient funds. You can also reverse a receipt if you want to re-enter and reapply it in Receivables (although you can just unapply and reapply, rather than reverse if you prefer). You can reverse cash and miscellaneous receipts before or after they are posted to the General Ledger, and before or after they are applied. Receivables lets you create two types of reversals: Standard Reversal: With a standard reversal, Receivables creates reversing journal entries for your general ledger and reopens all of the debit and credit items that were closed with the original receipt. You can create a standard reversal for cash and miscellaneous receipts, as well as a transaction related to a chargeback as long as there is no activity against the chargeback and the chargeback has not been posted to the general ledger. You also cannot process a standard reversal for any receipts that have adjustments or chargebacks that have been posted to the general ledger. For these exceptions, a debit memo reversal must be used. AR assigns the GL date and reversal GL date as the current date. If the current date is not in an open period, then it assigns both dates as the last date of the most recent open period. If the original GL date of the receipt is later than the current date, then Receivables uses the original GL date. You can change the reversal GL date and GL date to any date in an open period that is on or after the original GL date for the receipt. Debit Memo Reversal: Debit memo reversals are typically used when a standard payment reversal cannot be done. Debit memo reversals are required when you want to reverse a receipt that was previously applied to a chargeback and the chargeback has activity against it (such as another receipt, credit memo, or adjustment); or when chargebacks or adjustments have been posted to the General Ledger for the receipt you want to reverse. Receivables does not update any of the activity associated with the original receipt when you create a debit memo reversal. Instead it creates new receivable debit items for the items closed by the original receipt. You cannot process a debit memo reversal for a miscellaneous receipt.

Receivables Application

Applies Payment Schedule of Receipt with that of Transaction (m:n relationship) Can apply against On Account, CM, Receipt WriteOff (provided within Approval Limits) too. Mandatory: Apply Date, GL Date DB effect o Adds 2 records of Receivables Application (+ APP record and corresponding UNAPP record o Updates Amount Applied of Payment Schedule record of both Transaction and Receipt. On full application, the status gets updated from Open to Close Open Amount calculations o Open Amount for invoice or credit memo = Open Amount Application Discount o Open Amount for Receipt (for application with debit item) = Open Amount Application o Open Amount for Receipt (for application with credit item) = Open Amount + Application You can overapply to a Transaction (i.e. Open Amount gets negative), provided Transaction Type allows that Unapply Discount settings at System Options o Allow Unearned Discount (Y/N): whether to allow discount after Discount Date o Allow Discount on Partial Payment i.e. partially pay remaining open amount Payment Netting: Apply Receipt to Receipt. This provides you with an efficient approach to settling open cash, because it eliminates the need to open multiple receipts to apply on-account and unapplied cash. Once in the Applications form, go to Tools and check the Include Open Receipts checkbox. On-account application Reverse an application (I.e., Unapply) You may apply at the level of the individual lines (Apply in Detail) too An application may have no or one discount An application may have 0 to many CBs Customer account balance = Invoice +/- Adjustment CM Receipt. Application does not alter this balance Receipts may be transferred to GL without application Receipt write-off functionality is provided to account for small overpayments that you do not intend to refund or maintain as unapplied amounts or on account balances. With this function, you can choose to write off an unapplied cash receipt amount, within certain limits. The write-off amount is credited to this account, such as a miscellaneous revenue account, and no longer reflects as an unapplied amount on the receipt or on the customer's account. You can write off individual unapplied receipt amounts during receipt application or later, at any time using the Applications window. You can also write off balances of multiple receipts with the 'Automatic Receipts Write-Off' Program.

(Pre-requisite: You need to define the Write Off limits per Receipt at the System Options) Total Receipt Amount for identified receipts = Unapplied + Applied + On Account + Receipt Write-Off

How do you apply payments to unrelated customers' invoices?

The correct way to apply a receipt to more than one customer is to either establish a relationship between the customers or make sure the System Option - Allow Payment of Unrelated Transactions is checked.

What do you do with invoices that have credit balances?

Create a zero-dollar receipt and apply it to the invoice. This will give the zero-dollar receipt a positive balance that can be used to pay off other invoices. (The invoice, of course, gets closed) AR does not allow a receipt to be applied to the same transaction twice in the Receipt Workbench. However, you can change the original line applied to the invoice and increase the applied amount by the unapplied portion that you want to apply. In Rel 11.5.10,multiple applications to the same invoice are now allowed for lockbox and quickcash receipts for the purpose of managing deductions How do you refund an overpaid (on account) receipt? How do you refund a receipt for returned goods? How to issue a refund to Customer's credit card?

C:\Users\ Adm inistrator\Desktop\Oracle\Metalink downloads\AR\Refunding Receipt.doc

Receipt Line Level application (R12 feature)

C:\Users\ Adm inistrator\Desktop\Oracle\Metalink downloads\AR\Receipt Line Level application.doc

What date does AR use to calculate earned discounts?

When determining the discount percent for earned discounts, Receivables uses the invoice date, discount grace days, and the apply date of the receipt to determine the discount percent for this payment term.

Chargeback
Use chargebacks to create a new debit item for your customer when closing an existing debit item. This allows an aged debit item to be re-invoiced to a new debit item using the chargeback adjustment receivables activity. Perform CB during application.

You can charge back an open item either totally or partially (i.e. if $10 is open for an invoice, you may charge back only $6) On charging back, a CB DM gets created its amount is equal to the amount of the original invoice that is charged back. Charged back invoice gets adjusted down. The transaction type for a CB should be of a Class of Chargeback. Oracle has provided a seeded Transaction Type: Chargeback The account for a CB is derived from the Chargeback Adjustment Receivables Activity Every CB has a due date against it. In System Options, you may specify either of the following options as the default due date for the CB. o Open Invoice Due Date Use the due date of the invoice or debit memo as the default. o Receipt Date Use the receipt date as the default. This will be the date receipt was entered. o Current Date Todays date. o Deposit Date Use the receipt deposit date as the default. You may reverse a CB. The Chargeback that was generated gets closed. CB and Adjustment are allowed, only if the Profile Option AR: Cash Allow Actions is enabled.

Accounting
Event Invoicing Cash Receipt Cash Application Miscellaneous Receipt Dr AR Cash (Defined at Rec Method. Remittance Bank Account) Unapplied Cash Cr Revenue Unapplied/Unidentified (Defined at Rec Method. Remittance Bank Account) AR/ On Account/ Receipt WO Revenue (As defined fore the Receivables Activity. Can be overwritten)

Open Amount Calculations

Invoice Open Amount = Open Amount Application Discount CB(s) Receipt Open Amount = Open Amount Application (in case of application to debit items e.g. invoices or DMs or to On Account or to Receipt WO) = Open Amount + Application (in case of application to CM)

Lockbox and QuickCash

Auto lockbox is a program available in Oracle Receivables which helps you to import payments or receipts. In real world, Banks would provide data files which would have information about the payments made by customers. Receivables auto-lockbox program would help you in importing information from these data files into your system.

High level overview of the process is as follows

Once the lockbox data is received from banks, move it to a directory, normally a data directory. Control file will be placed in $AR_TOP/bin/ as a .ctl file. One can customize the layout and ctl file by deciding what data you will be receiving and what format will be used. Autolockbox has three steps: Import: Reads the lockbox data from bank file, moving it to the lockbox tables using SQL* loader script. (It is not necessary to use the import step of lockbox, data can be imported through SQL*Loader or any other custom program to populate data in the interface table.) Validation: The validation program checks data in the AutoLockbox tables for compatibility with Receivables. Once validated, the data is transferred into QuickCash tables (Intermediate_Cash_Rec & Intermediate_Cash_Rec_Line). At this point, you can optionally query your receipts in the QuickCash window and change how they will be applied before submitting the final step, Post QuickCash. (You can enter QC Receipts directly in the QC tables as well). Post QuickCash: This step applies the receipts, using AutoCash rules, and updates your customers balances. Cash Receipt tables are updated. These steps can be submitted individually or at the same time (i.e. the Submit LockBox Processing form) Lockbox details see attached file

C:\Users\ Adm inistrator\Desktop\Oracle\Metalink downloads\AR\Lockbox Details.doc

AutoCash
Post QC uses AutoCash Rules to apply Receipts. Further it uses Application Rule Sets defined at System Options. Following are the Autocash rules you can use: Match Payment with Invoice Clear the Account Clear Past Due Invoices Clear Past Due Invoices Grouped by Payment Term Apply to the Oldest Invoice First You cannot overapply a receipt to an open debit item using AutoCash rules. However you can overapply receipt to an invoice (if the Allow overapplication option on the invoice transaction type is set to Yes and profile option AR: Allow Overapplication In Lockbox is set to Yes) if you are not using AutoCash rules. Define AutoCash Rule Sets to determine the sequence of AutoCash Rules that Post QuickCash uses to update your customers account balances. It can contain maximum 5 rules. Example of an AutoCash Rule Set is as follows: Sequence 1 2 3 AutoCash Rule Apply to oldest invoice first Clear past due invoices Clear the account

Post QuickCash first checks the customer site, then the customer profile class, and finally at the system options level to determine the AutoCash Rule Set to use. How to define AutoCash Rule Set see attached file

C:\Users\ Adm inistrator\Desktop\Oracle\Metalink downloads\AR\AutoCash Rule Set - how to define.doc

Automatic Receipt
The Automatic Receipts feature allows you to automatically generate receipts for customers with whom you have predefined agreements. These agreements let you collect payments on time by transferring funds from the customer's bank account to yours (Remittance Bank Account) on the receipt maturity date. The Automatic Receipts feature satisfies the many variations of bank remittance processing, such as direct debits.

Once the receipts are created, they can be applied in the same way as manual receipts.

The following graphic provides an overview of the Automatic Receipts and Remittance flow:

The steps in the process are as follows: Flag invoices. Receipt Method = Automatic Receipts, enter Customer Bank Account (Payment Method is the payment medium by which the customer chooses to remit payments to you e.g. bank account transfer, credit card) Create Receipt. (Receipt. Receipt Method. Receipt Class.Creation Method) = Automatic. 1 per Customer/Customer due date/Invoice/Site/Site due date, depending upon Receipt Method.No of Receipt Rules If the Receipt Class of the Receipt needs Confirmation, send the Receipt to the Customer for confirmation. Resume the process after the Customer confirms Create Remittance Send to bank the remittance data file (tape/disk/email) in a pre-defined format e.g. BACS

Bank transfers funds on or after the Receipt Maturity Date. This date depends upon Receipt Method. Receipt Maturity Date rule, in case invoices with different due dates are being paid. The valid values are: Earliest, Latest Bank sends the statement to the performing organization. Clear Receipt (i.e. Dr Cash)

Collection
Days Sales Outstanding = (Total AR)/ (Total sales for the prior DSO Days)* (DSO Days)

Dunning Letters
Reminder of overdue invoices. Dunning methods: Days Overdue, Staged Dunning. Days Overdue Example Letter No 1 2 3 Days Overdue 5-15 16-45 46-

In this case, the DL Generate program identifies 5 Past Due invoices for a particular customer. The oldest of them falls in the 46+ days category. Letter 3 will be sent to the customer. Staged Dunning Dunning Level is the number of times a debit item has appeared on a Dunning Letter. Example Dunning Level Range 0-1 2-2 3-999 No of days 15 20 30

At least 15 days must pass before a debit item can appear for the 2nd time on a DL. Suppose an invoice 101 was selected for the first time by DL Generate program. The invoice is assigned Level 1, and is printed on Letter 1. The program was run next 17 days later. The Dunning Level got incremented to 2, and the invoice is now generated on Letter 2. If on the other hand, Dunning Level of invoices 102 and 103 got incremented to 3, a 2nd DL will be generated.

Thus for any customer, only one letter is generated in the Days Overdue method (depending upon age of the oldest invoice). On the other hand, multiple letters may be generated in Staged Dunning method. Also in the latter, all past due invoices are not included (if run within minimum days). Letter Set Indicates letter to be sent against each date range (for Days Overdue) or each Dunning Level (for Staged Dunning) Example Days Overdue 5-15 16-30 31-9999 Letter Name Standard1 Standard2 Standard3

It also contains switches e.g. whether to include Current (for each letter), whether to dun disputed items, levy Finance Charges, resend last letter (after last letter of a LS has been sent) Program DL Generate DL Print Purpose Determines which customers should receive a DL and indicates the invoices that should appear on the letter. Run for As-Of-Date, Letter Set and Dun Method. Produces a letter for each of the customers selected in the above step

You can create a custom DL in the Create DL window

Statements

A statement shows all account activity in a particular time frame since the last statement. Unlike Dunning Letters which show only overdue items, a statement shows all activities (including CB, Commitment). If a statement site is defined for the customer (only 1 active allowed per customer), send consolidated statement (for all Bill- to-Sites) to this site. If not, send individual statements to Bill-To-Sites with the Send Statement flag enabled. A statement is printed under a Statement Cycle. The latter determines frequency with which customers receive statements. Statement Cycle Statement Date (e.g. 3-Jun, 3-Aug, 3-Oct) Say a statement got printed for 3Jun but skipped for 3-Aug. In that case, when statement is printed for 3-Oct, it will include a) all activities between 3-Jun and 3-Oct b) debit items for all prior periods. You can determine Statement Aging Buckets (e.g. 01-5, 16-30, 31-) that will appear on the statement.

Cross Currency Receipts

Receipt and invoice that are applied to each other are in different currencies. On application, AR converts both amounts to the functional currency and calculates

Forex Gain <Loss> as Receipt Amount (as of Receipt Date) Invoice Amount (as of Invoice Date) For cross currency receipts, the customer needs to provide remittance info i.e. the invoices to which the Receipt needs to be applied, and the Applied Amount for each invoice e.g. for a Receipt of EUR 500, the customer sends the following Remittance Info: Invoice Amount USD 500 GBP 350 USD 400 Amount to be applied USD 200 GBP 100 USD 250 Allocated Receipt Amount GBP 150 GBP 120 GBP 190 GBP 460

Invoice # 501 502 503 Total

On account = EUR (500-460) = EUR 40 The Amount to be applied and Allocated Receipt Amount are fields on the Applications window. Instead of Allocated Receipt Amount, you may enter exchange rate. The Currency gain/loss is displayed on the Applications window. Accounting Dr Unapplied Cr AR Dr Currency Loss (as defined in System Options) 2 JEs are generated: one in functional currency and the other in Receipt currency. The functional currency JE is balanced. The Receipt currency JE is not balanced, and GL creates a balancing line with the Suspense account as the CCID (Define the Suspense account with Category as Cross Currency and Source as Receivables).

AR Open Interfaces
The AR Open Interfaces are: Customer, Sales Tax Rate, AutoInvoice, AutoLockbox.

GL Transfer
Distribution Type Revenue, Unearned Revenue, Unbilled Receivable Cash Receipt, Applications, Adjustment Miscellaneous Cash Transaction Invoice/CM Line Table Transaction Line GL Distribution AR_Distribution, Receivable Application, Adjustment Miscellaneous Cash Distribution

GL Transfer can be either in Detail or in Summary Journal Import summarizes distributions with same CCID, if GL Transfer flag is Summary. This is unlike AP, where summarization is done by the GL Transfer program itself.

Exclusions
1. AutoInvoice 2. AR Tax 3. Late Charges