Billing Platform Integration with Oracle Cloud Receivables Methodology

Many subscriptions billing technology companies are implementing Oracle cloud. These companies use the Oracle Cloud Receivables module to book subscription sale & leverage the robust Oracle Fusion Receivables Revenue Recognition process. However, it is crucial to building a methodology to integrate the billing platform with Oracle Fusion Receivables.

The following processes should be considered for integrating billing data with Oracle Cloud Receivables.

Identify middleware to communicate between the Billing platform and Oracle cloud receivable:

Many middlewares are available in the market, like OIC, SOA, Dell Boomi, Jitterbit, etc.

Businesses must procure any of the above middleware software licenses.

Identify communication methods to process billing data, book it as a sale, and recognize revenue in Receivables.

It is important to validate how the billing platform can make this data available. There are many ways to gather data from the billing platform.

• API: Here, the source system has inbuilt services that can be leveraged to pull data in a specific format.
• Connectors: Here, the source system makes available data fields in connectors. All data is available in these fields. The integrator should identify these data fields and fetch related data from these connectors by writing scripts and queries.
• FTP: Here, the source system gives data in a file, which can be in various formats like CSV, Spreadsheet, etc. The source system should pull these files to a particular data server location using internet protocols (IP addresses). The integrator uses these files to fetch related data from them.

Data Massaging, Validations, Mapping & Storage

It is necessary to validate and massage data before importing it in Oracle Cloud Receivables.

• Massaging: Oracle cloud accepts this billing data in a specified manner. It is essential to validate and add additional information if it is not there before moving it to the Receivables Interface tables. Common data elements can be grouped and imported as a single invoice in Receivables per business requirement. e.g., record lines with the same customer, transaction date, and currency can be grouped as a single invoice with multiple lines of different SKUs, Revenue Recognition date, etc. These lines can also be grouped by SKU, Revenue Recognition dates, etc.

• Data Validations and Mapping: Source system data must be validated before importing it in Receivables, like Customers, Items (SKUs), Sales Reps, etc. It should be validated with Receivable master data. If the same is unavailable, it can be treated as new and created. The need to map this data as per the business rule with Oracle Receivables specifications like customer classification mapped as Receivable Transaction Type, or billing Source mapped as Receivable Transaction source or source system SKU mapped with Receivables SKUs.

  Certain data elements are not available in the Source system. These can be hardcoded before inserting them in the receivables interface table, e.g., Ledger Name, Business Unit, Accounting Rule, Invoice Rule, Payment Term, Remit-To address, etc.

• Data Storage: It is necessary to have a staging table to perform the data mentioned above massaging & validations. This table can be a part of any on-demand cloud computing platform like Amazon Web Services or a business-owned server.

Data Import

Massaged data is available to import in the Receivable interface table. Middleware should use web service functionality to load data in the interface table, then call Auto invoice functionality to import data by source as multiple billing platforms in Oracle Cloud Receivable.

Error handling

There are three stages where errors should be identified.

• Staging table: Here, data is inserted from the source system. There is a possibility of an error while inserting data, like insufficient data where fetched data is not as per the staging table field or the connection is broken. These errors should be identified by middleware and notified to process owners.

  Processes should be designed to correct the data at the source system and re-process it, or UI should be designed to correct this erroneous data in the staging table by the user.

  Erroneous data should be flagged separately and archived if corrected data is re-processed from the source system.

• Interface table: Here, data is inserted from the staging table.

  Oracle Receivable performs its data validation in this process. There is a possibility of error due to insufficient data not identified at staging table validation, like wrong ledger ID, business unit ID, customer ID, or connection error. These errors should be identified by middleware and notified to process owners.

  Processes should be designed to correct erroneous data in the staging table by using UI or mapping to be updated to process data in the staging table. Data can be corrected at the source billing system and re-processed. Erroneous data should be flagged separately and archived if corrected data is re-processed from the source system in the staging table.

• Receivable Base Table: Here, data is imported from the interface table.

  The auto Invoice import process performs numerous validations to create Receivable transactions (Invoice/Credit Note). Auto Invoice rejects the entire batch of records if it identifies any error. These errors are identified in the Execution report. This report should be notified to process owners. Receivable provides UI to correct any errored data in the interface table.

  Errors can be due to inaccurate data from the source system, like wrong customer name, SKU, or currency, or wrong mapping in the staging table to derive some fields from creating Receivable Transaction like Ledger ID or Business Unit ID.

  Processes should be designed to either correct these error records in the interface table using UI or reject error records, and right/update errored data in the source system and re-process it. If the mapping is wrong, update/create mappings in the staging table and re-import it. Oracle Receivables will never import rejected/errored data in Receivables. These rejected records in the interface table can be purged.

Notifications:

There are two types of notifications: Success & Errors. These notifications should be generated in all stages of data transfer, like staging, Interface, and Receivable base tables. Notifications can be alerted by email to the process owners.

• Stage Table: Here, data is transferred from the source system. All success and error records should be notified to process owners in a detailed or summary report. The process owner should take appropriate action as per notification.
• Interface Table: Here, data is transferred from the staging table. All success and error records should be notified to process owners in a detailed or summary report. The process owner should take appropriate action as per notification.

• Base Table: Here, data is transferred from the Interface table. Auto Invoice generates its Execution report, which shows the detailed error and success record count summary and errors. This report should be notified to process owners to take appropriate action.

  The processes mentioned above help design this integration with Oracle Receivable.