Credit Card Chargeback

A credit card chargeback takes place when a credit card holder disputes a charge with the credit card company (e.g. VISA) and the credit card company issues a chargeback to the customer for the disputed amount and notifies the vendor that they have issued a chargeback to the customer.

A cardholder can request a charge back for many reasons including, but not limited to:

Charges for undelivered goods
Charges for goods or services different from what was ordered or if they received the wrong quantity of the goods or services ordered.
Charges for goods that were not timely delivered

In release 11i, we already have the functionality for the vendor to issue a chargeback directly to the customer. The customer can however also request a chargeback from the credit card issuer, so in release 12 - we are introducing the functionality for the vendor to also be able to register and process a chargeback that a card issuer has already issued to the customer.

Benefits:
Reduce costs by automating the credit card chargeback process

Credit Card Chargeback Process

After having received the credit card chargeback notification from the card issuers, the vendor will:

Find the receipt for which the chargeback was requested.
Un-apply the application line and subtract the amount of the credit card chargeback.
Apply the credit card chargeback activity on a new application line on the receipt. This automatically generates a negative miscellaneous receipt to the value of the chargeback.

If the vendor finds the chargeback to be valid, the vendor creates a credit memo to credit the invoice with the amount charged back.

If the vendor can prove to the credit card company that the chargeback was not valid, the vendor reverses the application of the credit card chargeback by:

Finding the receipt
Un-applying the credit card chargeback activity from the receipt. This automatically reverses the negative miscellaneous receipt
Restoring the original amount on the application line.

It is important to understand how our new Credit Card Chargeback functionality differs from the Credit Card Refunds we already have in 11i:

Credit card refunds: The merchant needs to refund the customer. So the negative misc. receipt must be remitted.
Credit card chargebacks: The customer has already received the chargeback, so the vendor will just need to record that a chargeback has taken place. The purpose of the misc. receipt is just to keep the accounting in place.

Business Process Steps

The business process that takes place when a credit card chargeback needs to be recorded is a three step process:

1.The vendor receives the receipt, records it and applies it to the invoice.
2.The vendor receives the Credit Card Chargeback notification and records the credit card chargeback by applying the credit card chargeback to the receipt
3.The vendor then needs to investigate if the Credit Card Chargeback is valid or not.

Based on the outcome, the vendor can choose to either:

-Acknowledge the credit card chargeback and credit the invoice, or
-Prove that the credit card chargeback was not valid, and after acknowledgement un-apply the credit card chargeback from the receipt

Credit Card Chargeback Process Receive Receipt

Example:
A customer visits a web store and orders goods for $100 using their credit card
The credit card company authorizes the payment and notifies the vendor of the receipt of $100
The vendor processes the receipt and applies it to the invoice.
Please note that there are no changes in how these activities are carried out in R12.

Let’s now take a look at the credit card chargeback process.

The customer receives the goods, but finds that goods for $25 are missing.
The customer files a dispute with the credit card company for $25
The credit card company credits the customer $25 and notifies the vendor that a chargeback of $25 has taken place.
The vendor applies the credit card chargeback to the receipt which generates a miscellaneous receipt to decrease cash with $25
Here we can see how the clearing account for the receivable activity of type ‘Credit Card Chargeback’ is used. It gets credited when the credit card charge back is applied and gets debited when the misc. receipt is generated.

Accounting Entries

Un-apply the receipt
–DR Receivables $25
–CR Unapplied $25

Apply the credit card chargeback
–DR Unapplied $25
–CR Credit Card Chargeback $25

Misc. receipt is generated
–DR Credit Card Chargeback $25
–CR Cash $25

Chargeback Process for Vendor:
1.Find receipt
2.Un-apply the receipt
3.Decrease the value on the receipt application line to $75
4.Apply $25 to receipt activity ‘Credit Card Chargeback’ (creates a negative misc. receipt of $25)

Validate Credit Card Chargeback

After the vendor has analyzed the credit card chargeback, the vendor can find the credit chargeback to be either valid or invalid.

The vendor can now either:

Acknowledge the credit card charge back and credit the invoice.
Prove to the credit card company that the credit card chargeback was invalid and un-apply the credit card chargeback from the receipt once it has been acknowledged by the credit card company that the credit card chargeback was invalid.

If the vendor acknowledges the credit card chargeback, the vendor simply credits the invoice by creating a credit memo for $25.

Credit the invoice by creating a credit memo
–DR Revenue $25
–CR Receivables $25

Vendor proves the chargeback to be invalid:

Un-apply the credit card chargeback
–DR Credit Card Chargeback $25
–CR Unapplied $25

Misc. receipt is automatically reversed
–DR Cash $25
–CR Credit Card Chargeback $25

Reapply the receipt
–DR Unapplied $25
–CR Receivables $25

Credit Card Chargeback Setup

Responsibility: Receivables
Navigation: Receipts > Receipts > (B) Apply > Applications > (B) Chargeback
Release 12 comes with the seeded Receivables Activity Type of ‘Credit Card Chargeback’.

The only setup step required is to create a new receivables activity of type credit card chargeback and specify the GL clearing account for the new activity.

Note: Only one activity of this type can be active.

I Create Accounting Program

The Create Accounting program processes eligible accounting events to create subledger journal entries. To create the subledger journal entries, the Create Accounting program applies application accounting definitions that are created in the Accounting Methods Builder (AMB).

The Create Accounting program,

Validates and creates subledger journal entries
Optionally transfers the journal entries to GL
Optionally posts the journal entries in GL
Generates the Subledger Accounting Program Report, which documents the results of the Create Accounting program

Draft Accounting

When you select draft accounting, Subledger Accounting creates the relevant journal entries in draft mode. Draft entries are not posted to General Ledger. You can review the resulting entries, update the transactions, or update the accounting rules. Any changes will be reflected when the transaction is processed again for accounting.

Online Accounting (Final)

Final entries are ready to be transferred to General Ledger and cannot be modified. The transactions are considered as processed for accounting. Any changes to the rules will not impact final entries.

Straight-Through Accounting (Final - Post)

If you select Final Post, Subledger Accounting posts the journal entries all the way through to General Ledger. This means that you can update GL balances straight from the invoice entry (or any other transaction entry) window.

Create Accounting Program

The Create Accounting program creates subledger journal entries. In general, the parameters described in the table above determine which accounting events are processed.
Navigation Paths (example Payables)
Payables: Other > Requests > Run
Receivables: View > Requests (B) Submit a New Request

Paramaters

1. Ledger - Required; limits accounting events selected for processing to those of a particular ledger. This program is run for primary ledgers or valuation method enabled secondary ledgers. Any reporting currency or secondary ledger associated with the selected primary ledger is also processed; i.e. entries are generated for the selected primary as well as reporting currencies and non-valuation method secondaries.

2. Process Category - Optional; restricts the events selected for accounting to a particular process category. For example, Invoices.

3. End Date - Required; end date for the Create Accounting program; processes only those events with event dates on or before the end date

4. Mode (Draft/Final) - Required; determines whether the subledger journal entries are created in Draft or Final mode

5. Errors Only (Yes/No) - Required; limits the creation of accounting to those events for which accounting has previously failed

6. Report (Summary/Detail/No Report) - Required; determines whether to generate a report showing the results of the Subledger Accounting program in summary or detail format

7. Transfer to General Ledger (Yes/No) - Required if Mode is set to Final; determines whether to transfer the subledger journal entries to General Ledger

8. Post in General Ledger (Yes/No) - Required if Mode is set to Final; determines whether to post subledger journal entries in General Ledger

9. General Ledger Batch Name - Optional; user-entered batch name that appears on the transferred General Ledger subledger journal entries. Transfer to GL option must be set to Yes.

10. Include User Transaction Identifiers (Yes/No) - Required; controls whether the report displays user identifiers' names and values.


Create Accounting Program

The Create Accounting program generates one or more accounting programs depending on the volume to be processed. The Subledger Accounting Program report is generated by the Create Accounting program and documents the results of the Create Accounting program. It lists the following:

Successful events and the subledger journal entries created for those events
Errors for failed events

You can run the report in summary, detail, or no report mode which are described as follows:
Summary mode provides a summary of events processed and detailed information about their errors.
Detail mode provides details of subledger journal entries generated from the processing of completed events and a detailed error report.
No report mode will show an error count without actually generating the report.

II Transfer Journal Entries to GL Program

The Transfer Journal Entries to GL program enables you to transfer any eligible journal entries to General Ledger, including those from previous runs that have not yet been transferred to General Ledger.

Note: This program is used if you run accounting online in Final mode (not Final Post) or if you run the Create Accounting program and set the Transfer to GL parameter to No.

The only reason you would want to run the Create Accounting program and set the Transfer to GL parameter to No is if you want to run accounting at different intervals than the GL transfer, for example, you may run accounting every hour but only transfer to GL nightly.

The Transfer Journal Entries to GL program consists of a subset of parameters used in the Create Accounting program as listed below:

–Ledger
–Process Category
–End Date
–Post in General Ledger
–General Ledger Batch Name

III Oracle Subledger Accounting Program Report

The Subledger Accounting Program Report is generated by the Create Accounting program and lists the following:

•Successful events and the subledger journal entries created for those events
•Errors for failed events

You can run the report in summary or detail mode as follows:
•Summary mode provides a summary of events processed and detailed information about any errors.
•Detail mode provides details of subledger journal entries generated from the processing of completed events and a detailed error report.

Transfer Journal Entries to GL Report

The Transfer Journal Entries to GL report is generated by the Transfer Journal Entries to GL program and lists the following:

Transfer to GL Summary
Errors

Setting Profile Options

The profile options listed above relate to data access and security and impact how accounting is generated through SLA in R12.

1. SLA: Enable Subledger Transaction Security in GL

Use this profile option to combine subledger transactions security with data access security for General Ledger responsibilities when drilling down to multi-organization enabled subledger application. Transaction security in the respective subledger application is always applied when drilling down from subledger transactions to subledger journal entries.

2. SLA: Enable Data Access Security in Subledger

This profile option determines whether the General Ledger Access Set security mechanism is applied for a subledger application responsibility when viewing, reporting, or creating subledger journal entries associated with a given ledger. The General Ledger Access Set security mechanism is always applied for responsibilities associated with the General Ledger application.

The profile option enables you to combine data access security with subledger transaction security and therefore control access to subledger journal entries depending on the ledger to which they belong. For example, you can implement a Multi-Org Security Profile that allows you to create Oracle Receivables Invoices for two different operating units each associated with different ledgers but restrict drill-down from the subledger transaction to the associated subledger journal entry based upon the destination ledger contained in the Access Set.

3. SLA: Additional Data Access Set

The SLA: Additional Data Access Set profile option, in conjunction with the GL: Data Access Set profile option, controls which ledgers and balancing or management segment values you can access when logging onto a responsibility. If SLA: Enable Data Access Security in Subledgers is enabled for the responsibility, you have access only to the ledgers and balancing or management segment values included in the data access sets assigned to the SLA: Additional Data Access Set and GL: Data Access Set profile options.

4. SLA: Allow Reports Journal Source Override

This profile option applies only to the following reports:
-Open Account Balances Listing
-Third Party Balances Report

Enable this option to change the Journal Source parameter during report submission. If the option is set to No, then you cannot change the value defaulted during report submission.

For example:
Should the general ledger data access set security be enforced when generating accounting? For example, should journal entries be created if the user does not have ledger clearance even if they may have multiorg access to the operating unit?

Should the transaction security model be applied when drilling down from GL? For example, should the user be allowed to inquire on journal entries of certain operating units if they do not have MO access, but have ledger clearance?

If there are secondary ledgers and data access set security is enforced in the subledger module, then an additional data access set needs to be assigned to the user to enable access to the secondary ledger.

Should the user be able to run certain reports across data from multiple subledger applications?