Streamlining Self-and Retro-billing for

Automotive Suppliers
Reinke Bonte
Executive Summary
Driven by competitive pressures, cost considerations and increasing globalization,
automotive enterprises are striving to automate business processes to improve
operational efficiencies. Among the several business processes in an organization,
billing and reconciliation are usually rife with complexities.
The self-billing building block provided by SAP R/3 is a step forward toward
automating complex business processes and enhancing efficiency. It allows a customer
to produce a credit note towards a vendor using the goods receipts issued by the vendor
as opposed to the conventional process of waiting for an invoice from the vendor before
processing a payment. While this customer credit note may match with the vendors
account receivables in most scenarios, it can also vary in others.
Retroactive billing is another unique business process of the automotive industry that
makes analysis even more complex. Retro-billing by definition has a very long lifecycle
sometimes beyond a year. This makes it a unique and potentially large challenge
with significant performance issues for automotive SAP users.
Minimizing discrepancies enables accurate financial reporting but it is a challenge for
the accounts receivable departments to achieve this in a timely manner. Reconciliation
can get extremely complex and time consuming when a large number of retro-billing
credit and debit notes are posted against an original self-bill credit note. As this
snowballs into thousands of documents requiring reconciliation, it is not possible to
execute manually.
This Infosys paper details challenges of this business process and discusses the gaps
of solution provided by SAP R/3. It provides couple of approaches which are scalable,
modular, integrated and flexible on how to manage this critical industry requirement.
It includes a case study that demonstrates how the ability to analyze this business
process makes a difference to revenue realization..
April 2007
2 | Infosys View Point
The Unique Automotive Business Process of Self-bill/Retro-bill
Business Requirement
Retro-active Price Changes
Automotive OEMs as customers usually leverage their strong bargaining power, resulting in suppliers accepting retroactive
price changes, succumbing and aligning to the market pressures faced by OEMs. These changes warrant that old invoices be
adjusted to new rates. These iterations are often repeated, some dating back beyond a year.
Customers Raise Billing Documents
Intensive competition and just-in-time production forces OEMs and suppliers to integrate their business processes closely.
This coupled with the strong position of the OEM has led several suppliers to cede their right to raise invoices to the
customer.
The Process
Self-Billing and Retro-Billing
The customer evaluates receipts and transmits self-invoices to the supplier, who then needs to reconcile these invoices with
the internal invoice created with the outbound delivery. This process is called self-billing. The process of issuing credit or
debit memos after retroactive price adjustments is usually referred to as retro-billing.
Internal invoice is posted in AR
Match Self-bill to internal invoice
Supplier ships goods Supplier Customer
Post Open Items for Value/Quantity Diferences
Negotiations for retro active price changes
Credit/debit memos created from Retro-Billing in AR
Match Self-bill to internal credit/debit memo
Post Open Items for Value Diferences
Execute Evaluated Receipt Settlement
Execute Retro-Billing
Payment Clear Internal Invoices
Update Pricing Conditions
Update Pricing Conditions
Execute Retro-Billing
Accounts Payable
Accounts Payable
Payment Clear Internal Invoices
Revenue Analysis and Open Items Write-of
Self-bill Sent to Supplier
Self-bill Sent to Supplier
Business
process fow
Infosys View Point | 3
Self- and Retro-billing Challenges
Business Challenges
The onus for these business processes rests on the supplier who must deal with their key challenges.
Identifying Self-bill References
Since each customer has a different business process and sends differently formatted EDI messages, the varying references
need to be linked correctly in the context of self-billing and the internal invoices that need to be matched. The customer
makes the payment as per the self-billing invoices transmitted. The supplier must then analyze which payment references of
the internal invoices can be considered cleared.
Root Cause of Discrepancies
Whenever discrepancies crop up between the self-bill and the internal invoice, the root cause needs to be isolated and
corrected. Often these issues can be traced to the master data, data entry, PO price variances or mis-configured interfaces on
the customer or supplier side. To this end, it is necessary to analyze each link in the chain.
Technology Challenges
High Number of Billing Documents
Frequent retro-billing and multiple discrepancies lead to a large number of billing documents posted in the system. As a
result of this, tracking high volume document flow gets extremely resource intensive. Processing and analysis can thus be
very time consuming.
Self- and Retro-billing in SAP R/3
Basic Support for Retro-billing
The standard SAP platform provides the retro-billing transaction VFRB. This transaction provides basic retro-billing
functionality enabling identification of invoice documents affected by retroactive price changes, choose the document type of
the credit and debit memos to be created, and execute creation of multiple documents.
Self-Billing Process Design in R/3
In SAP R/3, self-bill invoices are stored in independent self-billing tables, compared with internal invoices and only
discrepancies are posted as open items into Sales & Distribution and Finance modules.
Standard SAP R/3 provides iDoc type self-billing and the self-billing monitor (VSB1) which is used for automatic processing
of self-billing documents and root cause discrepancies or matching errors.
Business Process Gaps
Complexities of Financial Analysis
Self-bill invoices are not posted directly as invoice documents in the sales flow. This stores only the internal invoice and, if
there were discrepancies, open item documents. For this reason, there is no direct way of consolidated reporting on these
except from the self-billing monitor, which only gives detailed data per transmission and per delivery. The overall picture
remains elusive.
Drawbacks of Standard Retro-billing Transaction
The standard retro-billing transaction VFRB has usability issues. It can only be executed in the foreground, making it
unsuitable for the volume of retro-bills that are typically generated in the automotive industry.
The proposal list on which the user chooses the invoices to retro-bill does not provide enough detail for decision-making.
From a technical point of view the transaction is unfit for mass creation of credit and debit memos, because it only commits
to the database after all documents have been created. Until then it locks the number range object of billing invoices, which
4 | Infosys View Point
means that in some situations other processes simply time out while requesting a document number for billing invoice
documents. In the worst case this means that for hours no other process can create billing invoice documents.
Though such a situation could be alleviated by parallel buffering of the number range object, for legal reasons buffering
of billing invoice document numbers can be tricky. For example, the law in Italy requires that invoices are numbered
sequentially in a chronological order. If buffering is used to resolve the locking situation, the buffers need to be huge, which
will make it impossible to achieve a quasi-ascending order of numbers.
Another drawback of the existing retro-billing transaction is that the condition type which holds the price differences is hard-
coded. This makes later analysis of components of the price changes difficult.
Solution
Usability of retro-billing transaction
The proposed solution rewrites the retro-billing transaction that has plug-in features of:
Background processing - Due to the huge volume of retro-billing documents generated in automotive industry
Separation of Proposal Run and Execution - As there is often a time gap between the proposal and execution of large amount
of retro-billing documents
Integration with workflows - In order to ensure separation of duties in a company as it is often required that the person
executing the proposal and the person approving the retro-billing run need to be two different people
Level of Detail of the Proposal List, Integration with Excel (ALV) - As the proposal list from the standard VFRB transaction is a
multi-row list which cannot be sorted or downloaded in a format that allows easy analysis of this list
Definition of Condition Types for Retro-billing Differences - As it is required to define different condition types for different
kinds of price changes in order to facilitate detailed reporting on price changes. As this is the point where the enterprise
generates revenue, retro-billing is a key transaction for automotive industry users and needs to be accorded due attention.
Consider the Document Flow
The fact that one invoice can be retro-billed several times can lead to an ever-extending sales document flow, although a lean
design is desirable from the performance perspective.
Approach 1
The choice of the right approach from different strategies available to achieve a lean document flow depends on the companys
business processes. The standard recommendation is to have one sales document per item. The advantage of this approach is that
materials can be easily retired and locking issues are avoided. On the other hand, the key disadvantage could be that customers
or interfaced systems require multi-item sales documents.
Approach 2
Another approach to reducing document flow is to switch off the link between sales order and deliveries. One large automotive
supplier discovered that this link was not required in the case of scheduled orders. It realized it was possible to delete about
30 million entries in the document flow. This resulted in reducing the processing time of retro-bills and most other sales and
outbound logistics processes manifold, which had reached critical performance levels putting the companys ability to do
business in danger.
Integration with SAP BW
There is no automatic reconciliation tool available to analyze and reconcile the discrepancies raised between supplier invoices
and customer self-billing transmissions in terms of price and quantity. Hence a solution is needed to address this gap. The
SAP Business Warehouse is the tool of choice for analytics. However, there are no standard cubes available to analyze self-bill
invoices.
Infosys View Point | 5
The supplier sometimes needs a higher level view, e.g., on a per customer group level to see differences and open items
and then drill down to single transmissions and even self-bills and their items to understand where the discrepancies have
accumulated. When custom fields are involved, a new reporting solution can make the difference between success and
failure.
Open Items
Aging
Discrepancies
Region
Transmission
Customer
Customer
Group
Delivery
Material
Conclusion
Standard SAP provides basic support for the self- and retro-billing business processes for the automotive industry. However,
to use these processes on a large scale would need a large number of custom adjustments. Since the business process is
more complex on the supplier side, this is where we find the biggest pain points. These challenges pertain to the usability
and scalability of the standard retroactive billing transaction and reporting on self-billing transmissions and their financial
analysis. Infosys recommends that any implementation of self- and retro-billing processes in SAP must consider changing the
retro-billing transaction and involve BW report development especially if the data volume is significant.
Appendix
Case Study
A Tier-1 Automotive Supplier Obtains Clarity On Received Self-bills
A large tier-1 automotive supplier was struggling to deal with cleared payments and open items of its self-bill
customers. Custom discrepancy and aging reports that ran on R/3 were not able to cope with the amount of
documents produced from self- and retro-billing.
Infosys partnered with the client to devise a unique solution that was built from conceptualization to deployment
leveraging its R/3 and BW capabilities. The solution was designed to provide reports post-reconciliation summarizing
the errors/discrepancies (sometimes running into millions of dollars). The report is provided to the accounts
receivables department for action.
The
Solution
Benefts of this custom solution:
- Provides multi-dimensional analysis and reporting with drill down capabilities
- Ability to handle and analyze large volumes of data without timing out issues
- Performs analysis of cash discrepancies based on invoice/retro billing and cash received
- Provides accurate summary to business owners for write-ofs or collection

Report
Billing Detail (ODS)
(12.5 M records)
M
u
l
t
i

P
r
o
v
i
d
e
r

Extractor Table
Billing Detail


Extractor Table
Self-Billing Detail
Self-Billing Detail (ODS)
(6M records)
Report
Report Report
Report
Report
Jump
BW
R/3
Extractor
Program
Billing
Cube
(12M Rec.)
Self-Billing
Cube
(3M Rec.)
SAP BW
The operational data sources feed billing
and self-billing cubes. On the top of these
cubes sits the multi-provider on which
the reports are built.
SAP R/3
Extraction and calculation happen in R/
3 through a custom built extractor. This
extractor collects data by integrating SD,
FI and self-billing modules.
About the Author:
Reinke Bonte is a Consultant with Infosys SAP Practice. With around 5 years of SAP experience and 3 years in
the automotive industry, he focuses on facilitating solutions using SAP components in the areas of supply chain
management and logistics. Reinke holds a bachelors degree in economics and a post graduate degree in Asia Pacifc
studies. He can be reached at [email protected]