Balance Forward Billing - for Oracle Receivables Users

Applies to:

Oracle Receivables - Version: 12.0.0 and later [Release: 12.0 and later ]
Information in this document applies to any platform.

Abstract

This white paper provides an overview of the Balance Forward Billing feature in Oracle
Receivables Release 12. It discusses required set-up, provides sample screenshots,
debugging tips, code walk-through as well as other pertinent information related to the
feature.

1. Overview

Balance Forward Billing (BFB) is a new feature introduced in Release 12. It replaces the
functionality provided by Consolidated Billing Invoices (CBI) in Release 11i.

Balance Forward Billing is enabled when defining a customer. Once a customer record is
Balance Forward Billing enabled, you can print a single document, referred to as a
Balance Forward Bill which includes all of a customer's transactions and payments
created within the billing period as well as any balance carried forward from the
previous billing period. This allows you to send one consolidated document to the
customer instead of individual invoices per transaction.

Depending on how Balance Forward Billing is set-up, you can consolidate into one bill all
transactions and payments of a customer across multiple sites, or you can consolidate
per site.

It provides :

• a beginning balance carried over from the previous period

• an itemized list of all activities such as invoices, debit memos, credit memos,
adjustments and receipts
• an outstanding balance for the current billing period
• aging of outstanding balance

2. Features

1. Balance Forward Billing can be set-up at either the Customer Account or Site
level.
2. The format of the bill can be Detailed or Summarized.

Wednesday, July 13, 2011 Madhava Rao Mokka

Page 1 of 22
 3. Billing cycles can be defined to reflect your business requirements on how often a
customer should be billed. Billing Cycles can be Monthly, Weekly or Daily.
4. It provides the flexibility of excluding a particular site. It also allows you to pick
specific invoices that you do not want to be included in the Balance Forward Bill.
5. You can query using the Balance Forward Billing number in the Transactions
Workbench.
6. You can apply receipts to a Balance Forward Bill via the Receipts Workbench as
well as Automatic Receipts.

3. Set-up

The following set-up needs to be performed in the order listed.

a. Define Balance Forward Billing Cycles

Navigation Path : Setup - Print – Balance Forward Billing Cycles

You can define a cycle with a Frequency of Monthly, Weekly or Daily. You also specify
how frequently the cycle should repeat.

The cycle below, bills on the 18th of every month. In this set-up, cycle dates will be
created for 18-JAN-2008, 18-FEB-2008, 18-MAR-2008 and so on.

Wednesday, July 13, 2011 Madhava Rao Mokka

Page 2 of 22
The cycle below, bills every Monday. In this set-up, cycle dates will be created for 07-
JAN-08, 14-JAN-08, 21-JAN-08 and so on.

When a cycle is defined, records are created in the tables : AR_CONS_BILL_CYCLES_B

and AR_CONS_BILL_CYCLE_DATES. Ten years worth of cycle date records are stored in
the table.

The cycle date is later reflected in the Transaction workbench as Billing date.

Note:

There are 2 types of Billing Cycles: RECURRING and EVENT.

Users can only create cycles with RECURRING type, and Oracle seeds one EVENT type
named EXTERNAL. The EXTERNAL cycle can be used for imported transactions via
AutoInvoice, see section below on Balance Forward Billing in AutoInvoice.

b. Define Balance Forward Billing Payment Terms

Navigation Path : Setup – Transactions – Payment Terms

Wednesday, July 13, 2011 Madhava Rao Mokka

Page 3 of 22
A balance forward payment term needs to be defined with the Billing Cycle field
populated. Once the Billing Cycle field is populated this term is considered a Balance
Forward billing term.

This following payment term uses the BFB MTH cycle we defined earlier. The Due days
indicates the number of days after the Billing Date the invoice becomes due. In this set-
up, transactions that use this term will be billed on the 18th and will be due on the 28th.

In the following set-up, transactions that use this term will be billed every Monday and
will be due 5 days after that.

Wednesday, July 13, 2011 Madhava Rao Mokka

Page 4 of 22
 c. Define Customer Profiles (OPTIONAL)

Navigation Path : Customers - Profile Classes

Setting up a customer profile class is an optional step for Balance Forward billing set-up.
Having a customer profile class simplifies the set-up of Balance Forward Billing enabled
customers, as the values for fields pertaining to Balance Forward Billing are used to
default the values into the customer record. You can override values defaulted in from
the profile class.

When defining a customer profile class for Balance Forward Billing, you should check
the Enable checkbox. Once enabled, the fields for Bill Level and Type are enabled
and only Balance Forward Payment terms will be available in the list of values.

The set-up below is for a customer profile using Bill level = Account, wherein
consolidation is done at the account level, all activity from Balance Forward Enabled
sites are reported in one bill

Wednesday, July 13, 2011 Madhava Rao Mokka

Page 5 of 22
The set-up below is for a customer profile using Bill level = Site, wherein consolidation is
done at the site level, and several bills are created, one for each BFB-enabled site.

Wednesday, July 13, 2011 Madhava Rao Mokka

Page 6 of 22
Following provides an overview of the difference between the Bill Level values :

Bill Level = ACCOUNT

Wednesday, July 13, 2011 Madhava Rao Mokka

Page 7 of 22
When Balance forward Billing is enabled at the Account level, the result would be the
creation of one Balance Forward Bill. This bill will consolidate all the activities across all
the BFB-enabled sites for this account. In the scenario above, there are four sites. Three
of the sites are BFB-enabled. The fourth site is not. Note that for each BFB-enabled site,
a BFB payment term and type was defined. However, because the expectation in this
set-up is only one bill will be created, the settings at the Account level takes precedence
over the settings at the site level. In such a set-up, a Balance Forward Bill will
consolidate all transactions from these three sites and address the bill to the third site
since it is the Primary Bill-to site. All transactions for the fourth site will be excluded
from the Balance Forward bill, and instead each transaction will print an invoice.

Bill Level = SITE

When Balance forward Billing is enabled at the Site level, the result would be the
creation of several bills. Each BFB-enabled site will get its own bill. Each bill will
consolidate the activities for that site. In the scenario above, there are four sites. Three
of the sites are BFB-enabled. The fourth site is not. Note that for each BFB-enabled site,
the settings defined at the site level will be used to create its bill. All transactions for the
fourth site will be excluded from the bill and instead each transaction will print an
invoice.

d. Define Balance Forward Billing Enabled Customer

Navigation Path : Customers - Customers

When creating a BFB Customer, you have the option to use a BFB Profile class, such as
the ones created earlier, or you can use any profile class and just override the fields
highlighted under Balance Forward Billing and Terms.

Wednesday, July 13, 2011 Madhava Rao Mokka

Page 8 of 22
Below, we used the customer profile class : BFB ACCT LEVEL PROFILE, from which BFB-
related fields have defaulted from. Note the checkbox Override Terms. By checking this
box, you are saying that when a user creates an invoice for this customer, he is allowed
to change the Payment Term that defaults in. This feature allows you to create non-
balance forward transactions within a BFB-enabled site.

To demonstrate the scenario described in the overview for Bill Level = ACCOUNT, we
will define 4 sites for this customer :

Site Bill Level Payment Term Override Terms

SITE 1 : BFB Account BFB MTH checked = Y
SITE 2 : BFB Account BFB MTH unchecked = N

Wednesday, July 13, 2011 Madhava Rao Mokka

Page 9 of 22
 SITE 3 : BFB Account BFB WEEKLY checked = Y
SITE 4 : NON-BFB not set 30 NET checked = Y

Below, we used the customer profile class : BFB SITE LEVEL PROFILE, from which BFB-related fields
ave defaulted from. Note the checkbox Override Terms. By checking this box, you are saying that
when a user creates an invoice for this customer, he is allowed to change the Payment Term that
efaults in. This feature allows you to create non-balance forward transactions within a BFB-enabled
ite.

To demonstrate the scenario described in the overview for Bill Level = SITE, we will
define 4 sites for this customer :

Site Bill Level Payment Term Override Terms

Wednesday, July 13, 2011 Madhava Rao Mokka

Page 10 of 22
SITE 1 : BFB Site BFB WEEKLY checked = Y
SITE 2 : BFB Site BFB WEEKLY unchecked = N
SITE 3 : BFB Site BFB MTH checked = Y
SITE 4 : NON-BFB not set 30 NET checked = Y

IMPORTANT NOTES:

1. When you enable Balance Forward Billing at the ACCOUNT level, it is

still necessary to create a profile at the SITE level even though the settings
will simply inherit values from the ACCOUNT level profile.

If you do not explicitly setup a SITE level profile, you will encounter the
error below when you attempt to create a transaction:

Balance forward billing is enabled for this customer at the account level,
but is either disabled or not defined at site level.

2. When Balance Forward billing was originally introduced in Release

12, features such as cutoff date terms and consolidating invoices were only
available for customers who were Balance Forward Billing enabled. This
was very restrictive and required additional setup that was unnecessary for
customers who were not interested in the features provided by Balance
Forward Billing, but just wanted to use a balance forward payment term
that implemented cutoff days.

To lift this restriction, changes were made that allowed non-Balance Forward Billing
Enabled customers to use Balance Forward Billing terms with cutoff dates. This restores
the functionality that was available in Release 11.5. To use these features, you need to
apply the following patches:

• Patch 9343518: PROXIMA PAYMENT TERM ( AR) IN R12 NEED

5415213 WORKED AND RELEASED.
• Patch 9571316: WRONG DUE DATE CALCULATED ON
INVOICES WITHOUT BFB ENABLED
• Patch 9538417: PAYMENT TERMS WITH 'BALANCE FORWARD
BILLING' GIVING ERROR DURING AUTOINVOICE

Additional information on using cutoff terms can be reviewed in Note 1052906.1, How to
implement payment terms with cutoff days in R12

4. Simulation for Balance Forward Billing

Wednesday, July 13, 2011 Madhava Rao Mokka

Page 11 of 22
After doing the required set-up above, you can start creating transactions for these BFB-
enabled customers.

For BFB CUST 1 (Account Level) : To demonstrate the differences in behavior due to the
settings defined at the Site level, several invoices are created across each of the sites.

For SITE 1 : BFB, 2 invoices are created, to demonstrate that the Payment Term can be
overwritten due to Override Terms being checked.

For Invoice 12294 below, the Billing date is calculated using the set-up of the BFB
Cycle : BFB MTH, which we set up as the 18th of the month. The billing date has to be
on or after the Transaction Date and is calculated as 18-MAY-08. The Due date is
calculated using the set-up of the BFB Payment Term : BFB MTH which we set up to be
due in 10 days. The Due date is determined to be 28-MAY-08, which is 10 days after the
billing date.

For the Invoice 12295 below, we demonstrate that even though BFB is enabled for SITE
1 : BFB, a user is allowed to create a non-BFB invoice by changing the payment term to
a non-BFB term. This is allowed because Override Terms is checked in the Site Profile.

Wednesday, July 13, 2011 Madhava Rao Mokka

Page 12 of 22
For SITE 2 : BFB, we create one invoice, the screenshot shows the LOV for Payment term
showing that the only available term is BFB MTH. This is because the Override Terms
checkbox for this site is unchecked, so all transactions will have to use the term defined
at the Site profile. For SITE 2 : BFB, all invoices will have the payment term BFB MTH.

Wednesday, July 13, 2011 Madhava Rao Mokka

Page 13 of 22
For Site 3 : BFB, we create one invoice, the screenshot demonstrates that the Payment
Term used is BFB WEEKLY as defined in the Customer Site profile. Note that the Billing
Date and Due date are different from that calculated for BFB MTH, this is determined by
the set-up for the Payment Term BFB WEEKLY.

For Site 4 : NON-BFB, note that the field Billing date is not even displayed, the field
Billing Date is present only for BFB transactions.

Wednesday, July 13, 2011 Madhava Rao Mokka

Page 14 of 22
For BFB CUST 2 (Site Level), the following invoices are created :

Site Invoice # Payment Term Billing Date Due Date

SITE 1 : BFB 12312 BFB WEEKLY 05-MAY-08 10-MAY-08
12313 BFB MTH 18-MAY-08 28-MAY-08
SITE 2 : BFB 12314 BFB WEEKLY 05-MAY-08 10-MAY-08
SITE 3 : BFB 12315 BFB MTH 18-MAY-08 28-MAY-08
SITE 4 : 12316 30 NET not applicable 28-MAY-08
NON_BFB

After creating the above, we are ready to run a simulated test of Generating the
Balance Forward Bill.

5. Generating a Balance Forward Bill

Navigation Path : Print Documents – Balance Forward Billing

In an actual business scenario, Balance Forward Bills will be generated on a regular

basis. A business process will be defined so that the process is submitted at regular
intervals. In this example, the bills for BFB MTH have never been generated.

Wednesday, July 13, 2011 Madhava Rao Mokka

Page 15 of 22
Upon invoking this menu item, you have the following three options :

• BPA Balance Forward Print Program - enables you to reprint any Balance Forward
Bill
• Confirm Balance Forward Bill - enables you to confirm or reject Draft Bills
• Generate Balance Forward Bills - enables you to generate new bills

Note that the Billing date is not a mandatory field. If you do not specify a billing date,
the code will pick the latest value of the Billing date for the cycle that is on or before the
system date. In this example, if I ran the process on 14-JAN-09 and did not provide a
billing date parameter value, the code would have run the process with a billing date of
18-DEC-08. This is expected behavior for BFB. It will not print bills for each of the cycles
dates defined that you have not yet printed, but rather it will fast forward to the latest
value possible.

This process will spawn 3 requests : first to collect and process the data for the BFB,
second to kick off Bill Presentment Architecture (BPA) Print process and third to actually
create the output.

Following is the output for BFB CUST 1, invoices across the three BFB-enabled sites are
included. It shows Previous Balance = 0.00 because this is the first run for this billing
cycle. The three invoices qualified for inclusion into the Bill are those that used BFB
Terms. Note that even if the invoice for Site 3 : BFB was using the term BFB WEEKLY, it

Wednesday, July 13, 2011 Madhava Rao Mokka

Page 16 of 22
was pulled into this bill anyway. This is due to the setting of Bill Level = Account. Which
causes all settings at the Site level to be ignored, and instead settings at the Account
level are used.

Following is one of the outputs for BFB CUST 2, when submitted for BFB WEEKLY, each
site using BFB WEEKLY payment term gets its own bill :

Wednesday, July 13, 2011 Madhava Rao Mokka

Page 17 of 22
Data associated with a Balance Forward bill is stored in the following tables :

• AR_CONS_INV_ALL : a row is created for every BFB site included in the bill. Each
site will have its own CONS_INV_ID. When Bill level = Account,
several CONS_INV_ID values can have the same CONS_BILLING_NUMBER value.
• AR_CONS_INV_TRX_ALL : a row is created for every transaction, adjustment,
receipt pulled into the bill
• AR_CONS_INV_TRX_LINES_ALL : a row is created for every invoice line pulled into
the bill

The corresponding CONS_INV_ID values will be stamped into

AR_PAYMENT_SCHEDULES.CONS_INV_ID of all invoices included in the bill.

Since we generated the bill in Draft mode, we need to submit another process shown
below to accept it.

Wednesday, July 13, 2011 Madhava Rao Mokka

Page 18 of 22
The Confirm Balance Forward Bill process enables you to either Accept or Reject a Draft
bill. If you choose to accept, the invoices included in the bill are finalized. You can no
longer make any changes, or modifications to these invoices even if your System Profile
: Allows Change to Printed Transactions is Yes.

Important : When invoking the Confirm Balance Forward Bill to Accept or Reject Draft
bills, note that the only parameter marked as mandatory is the Confirm Option
parameter. However, the following fields have a requirement dependency upon each
other :

• Customer Number Low/High (required if bill number or concurrent Request ID is not

specified): Confirm one or more account-level balance forward bills. The listof values
includes all balance forward billing customers.

• Bill Number Low/High (required if customer number or concurrent request ID is not

specified): Confirm one or more balance forward bills.

• Concurrent Request ID (required if no other parameters are specified): Select the

concurrent request ID for the Generate Balance Forward Bill program to accept or reject
a batch of balance forward bills.

Wednesday, July 13, 2011 Madhava Rao Mokka

Page 19 of 22
If you happen to submit Accept or Reject without providing additional parameters, the
process will still run but will not do anything. The process will complete normal, but if
you view the log file, you will see a message like: ACCEPT : Cannot Accept Bills, user
needs to provide additional parameters.

Please monitor ER bug 8520340 which is a request to have the concurrent process end
in warning, instead of normal, so users are alerted to a "problem" encountered during
the Accept/Reject process.

If you choose to reject the bill, the invoices included in the bill are released, and they
can be picked up by a subsequent run of Balance Forward Billing. However, any invoice
whose BFB data was overridden by the Generate Bill process will retain the new BFB
data, it will not restore the original values.

Subsequent activity such as adjustments, credit memo applications, receipt applications

to the invoices included in the bill will be reflected in future bills generated.

The following output illustrates the next Bill created for the BFB MTH cycle. It shows
that prior to the next billing date of 18-JUN-08, a new invoice was created and an
adjustment and a receipt were created against 2 of the invoices included in the bill.

Wednesday, July 13, 2011 Madhava Rao Mokka

Page 20 of 22
Once an invoice has been included into a bill, you can use the View Invoice Icon
(highlighted below) to view the output of the bill to which the invoice is associated with.
Note that this icon will only display output, after the Generate Balance Forward Bill
process has been submitted, and this invoice has been included in a bill.

6. Balance Forward Billing in AutoInvoice

Wednesday, July 13, 2011 Madhava Rao Mokka

Page 21 of 22
 When importing transactions via AutoInvoice, the following fields in
Field Name Description
CONS_BILLING_NUM If the Balance Forward Bill was generated outside of Oracle Receivables, but you want
BER to keep track of the Billing number within Oracle Receivables, then you can provide a
value in RA_INTERFACE_LINES_ALL.CONS_BILLING_NUMBER.

AutoInvoice will validate whether this number already exists in AR_CONS_INV_ALL

where CONS_INV_TYPE = 'MINV'. If such a record does not yet exist, one will be created
to keep track of this externally generated Balance Forward Billing Number.
BILLING_DATE If using the Balance Forward Billing feature, and the billing cycle associated to the
payment term of this transaction has Billing type:

• EVENT, then you are required to pass in a Billing date. A Billing cycle with type
EVENT is considered an EXTERNAL cycle, whereby the Balance Forward Bill was
generated outside of Oracle Receivables.
Note 804334.1, Autoinvoice Error: AutoInvoice Validation Report Shows an Error
with Blank Text, discusses an issue addressed in AutoInvoice wherein a blank
error was raised for the case where the Billing Type = EVENT.

• RECURRING, then you should not pass in a value and AutoInvoice handles
deriving the billing_date for you.
TERM_ID or If you pass a payment term that is associated to a RECURRING Billing Cycle, then it is
TERM_NAME like you are simulating a manually entered transaction. AutoInvoice will take care of
determining the Due Date for the transaction, based upon the Billing Date derived from
the billing cycle information.

Please note that validation of this field against a balance forward billing enabled
customer changed after Release 12 was originally released. Refer to Note Box in setup
step: Define Balance Forward Billing Enabled Customer for additional information for
additional information.
RA_INTERFACE_LINES_ALL are related to the Balance Forward Billing feature:

Wednesday, July 13, 2011 Madhava Rao Mokka

Page 22 of 22