Billing Document Transfer to Financial Accounting 

Flexible Transfer Functions

Media Sales and Distribution contains special functions (programs) for use in transferring billing
documents to Financial Accounting. A distinction is made between the following transfer types according
to the different posting transactions in billing document transfer:

 Individual transfer
 Collective transfer
 Payment card transfer
 Collection transfer

Each transfer type corresponds to a transfer function (see the separate documentation on the transfer
type).

Transfer Time
You can perform billing document transfer at any time after billing. To do this, you must schedule the
corresponding transfer functions (programs) to be run in SAP background processing. Billing documents
can be edited up to the point at which transfer takes place.

Customizing Settings
 Accounting method for company code; IMG path: SAP Media  Media Sales and
Distribution  Periodical Sales and Distribution  Revenue Deferral  General Settings
 Definition of Accounting Method for Each Company Code.

The definition of the accounting method (for each company code) is a basic setting for
revenue deferral.

o In the German accounting method, revenue is only deferrable after billing

document transfer.
o In the Anglo-American accounting method, revenue becomes deferrable once the
service (delivery) has been performed regardless of billing document transfer.

 Transfer technique. Transfer can be performed using two different techniques:

o Via batch input (by creating and reading batch input sessions)
o Via the FI/CO interface by direct posting to financials (the FI/CO interface is the
standard interface with financials in the SAP R/3 System. If you use the FI/CO
interface for data transfer, you can define (summarize) the field list for the FI
documents.

IMG paths:
SAP Media  General Settings  Activation of FI Interface for Transfer (IS-M/SD)
SAP Media  Media Sales and Distribution  Periodical Sales and Distribution  Billing
 Transfer of Billing Documents to Financial Accounting  Define FI Document
Summarization (for FI/CO Interface).
  All the required settings for transferring billing documents to Financial Accounting (define
document types for Financial Accounting, maintain document types for billing, assign VAT
codes, convert payment methods for collective billing document transfer, define account
for VAT differences, define limit amounts for data medium exchange, define posting
periods for fiscal year); IMG path: SAP Media  Media Sales and Distribution  Periodical
Sales and Distribution  Billing  Transfer of Billing Documents to Financial Accounting.

 All the necessary settings for transferring revenue to Financial Accounting; IMG path:
SAP Media  Media Sales and Distribution  Periodical Sales and Distribution 
Revenue Deferral  Data Transfer to Financial Accounting  



 The assignment of G/L accounts must be maintained in Customizing for revenue account
determination. The first G/L account field (SAKN1) contains the revenue account and the
second G/L account field (SAKN2) contains the revenue deferral account. IMG path: SAP
Media  Basic Functions  Account Assignment  Account Assignment in Media Sales
and Distribution  Revenue Account Determination  Assignment of G/L Accounts.

Revenue Account Determination

The system performs revenue account determination during billing document creation. When this
is done, price conditions are assigned to a revenue account (or revenue deferral account) and the
surcharges and discounts are assigned to a sales deduction account (or revenue deferral
account). The settings for revenue account determination are defined in Customizing. IMG path:
SAP Media  Basic Functions  Account Assignment  Account Assignment in Media Sales
and Distribution  Revenue Account Determination.

You should note the following when assigning G/L accounts in Customizing for revenue account
determination:

 If you want to perform revenue deferral, assign the revenue account in the first G/L
account field (SAKN1) and the revenue deferral account in the second G/L account field
(SAKN2).

 If revenue deferral is not to take place, e.g. in the case of monthly advance billing, enter
the same revenue account in both G/L account fields (SAKN1 and SAKN2).

 If billing is performed retroactively, you only need to enter the revenue account in the first
G/L account field (SAKN1).

Transfer Block for Billing Documents

If revenue account determination cannot be performed correctly during billing, the system sets a
transfer block in the relevant billing documents during billing. You can use the analysis function
to identify the errored entries in the account determination tables. If the entries in Customizing for
account determination are correct, the system removes the transfer block from the billing
documents.

Revenue Deferral
Revenue deferral takes place during billing document transfer to Financial Accounting or during
amortization of orders with a liability account. During revenue deferral, the revenue is first
updated in a revenue deferral account and only posted on the due dates. The following types of
revenue deferral are possible:

 Period-related revenue deferral

Revenue for unlimited subscriptions for which billing is performed in advance is deferred
to the posting periods. For example, the revenue from a year's subscription is deferred to
twelve monthly posting periods. The deferred revenue is posted periodically, e.g. at the
end of the month, from the revenue deferral account to the real revenue account.

 Revenue deferral per issue

Revenue for unlimited subscriptions for which billing is performed in advance is deferred
to all the issues in the billing period. For example, the revenue from a year's subscription
is deferred to twelve copies. The deferred revenue is posted periodically, e.g. at the end of
the month, from the revenue deferral account to the real revenue account.

 Service-related revenue deferral with liability account

Revenue deferral does not take place during billing document transfer. This revenue
deferral type is only relevant for subscriptions with a liability account (renewal or delivery
subscriptions). Service-related revenue deferral with a liability account is processed
differently according to the accounting method. The revenue is normally deferred at the
amortization time of the issue delivered. Exception: If you are using the German
accounting method, revenue deferral only takes place at the amortization time if the billing
document has been created and transferred. This means revenue deferral is possible at
the following times:

o After billing document transfer when using the German accounting method
o Independently of billing document transfer when using the Anglo-American
accounting method

Forwarding Data to Financial Accounting 

The system can forward billing data in invoices, credit and debit memos to Financial Accounting and post
them to the appropriate accounts.

Accounts
Costs and revenue can be posted to the following accounts:

 Customer accounts receivable

 General ledger (for example, a cash clearing account)
 Revenue
 Sales deductions
  Accruals (for rebate agreements)

o Accrual account
o Accrual clearing account

The system automatically posts the amounts to the appropriate accounts by means of Account
determination.

Business Area
The system posts these costs and revenue according to the business area. The business area can be
equivalent to the:

 Sales area (if the accounts are to be posted according to sales)

 Plant/division (if the accounts are to be posted according to products)

The business area is defined in Customizing for Sales.

Reference Number and Assignment Number

Financial Accounting must be able to recognize that certain billing documents belong to one business
transaction. These documents are combined for this purpose.

Incoming payments may refer to a specific number (such as a customer purchase order number). For
clearing purposes this number can be used to find the relevant document quickly.

Also, if there are any cancellations or credit memos which are created on the basis of an invoice, it is
important for Financial Accounting to be able to recognize that these billing documents belong to one
business transaction.

For these purposes there are two special numbers in the billing document header which can be passed
on to the accounting document as follows:

 the reference number in the accounting document header

 the assignment number in the customer line item

The reference number can contain the number of the customer business transaction. This number can
be used as search criteria for changing or displaying the document. You can print the reference number
instead of the accounting document number in all business correspondence.

The assignment number provides additional information in the customer line item of the accounting
document. The account line items are sorted and displayed according to the assignment number.

Any subsequent documents, which relate to the invoice, such as a cancellation document, credit or debit
memo, etc., will have the same reference and/or assignment number. In this way the system can view
these documents as belonging to a single business transaction.

In Customizing for Sales, you can choose from the following to be used as a reference number and an
assignment number:

 A: Customer purchase order number

  B: Sales order number
 C: Delivery number
 D: external delivery number

 E: current billing document number

 F: External delivery number if available or, if not, the delivery number (used mainly in the
component supply industry)

The reference number and the assignment number can be entered as follows:

 manually in a sales order

Choose Goto  Header  Accounting: Reference field.

 automatically in a billing document:

o copied from the sales order

o automatically determined by the system

Choose Goto  Header Header detail: Assignment field.

Determining the FI Document Type from the Billing Type

You can assign an FI document type when maintaining the billing types.

If you do not make an entry, the system automatically assigns document type ‘RV’.

Combining FI Documents Using a Payment Reference Number KIDNO.

In some countries you may be required to combine receivables, linked liabilities or cancellations in the
same payment program.

This combination is carried out by filling field KIDNO in the billing header with the following values:

 F2 billing documents (customer invoices) with the billing number

 S1 cancellations using the reference to the corresponding F2 billing document to be canceled via
the VBRK-KIDNO from the F2 billing document.
 If a reference for the credit memo request exists for a billing document, then the VBRK-KIDNO
value of the reference billing document is copied.
 If there is no reference, then the KIDNO is given the current billing document number.

Transaction-Related Negative Adjustment

Offsetting entries in the SAP system have always been entered on the corresponding opposite side, e.g.
receivables on the debit side and credit memos on the credit side. In this way, the account could be
balanced even though sales volume entries were made on both sides of the account.
Now, you can use the billing type to determine whether 'negative adjustment' is to be carried out for
certain billing types. When maintaining the billing type you can set the following in the ‘negative
adjustment’ field:

 No entry:

no negative adjustment

 A:

Credit memos/cancellations with ref. to an invoice - negative if the postings are within the same
posting period.

 B:

Credit memos/cancellations with ref. to an invoice - always negative.

Value Date for Credit Memos

Credit memos that do not have a value date will be immediately due for payment on the billing date. This
means that the receivables and payables will not be reconciled.

When maintaining the billing types, you can choose the function ‘Set value date for credit memos’.

If this function has been selected in the billing type, the reference billing date has not been cleared, and
the baseline date for payment in the base billing document is after the billing date in the credit memo,
then the following fields are completed:

 VALDT (fixed value date) is filled with the baseline date for payment from the base billing
document, and the field
 REBZG (document number) is filled with the FI document number

The fields VALDT and REBZG are not completed for cleared base value billing documents.

Transferring Partner Functions to Accounting

You can use the indicator Branch/Head office to determine which partner functions should be transferred
to accounting when maintaining the billing type.

 blank: If the payer is not the same as the sold-to party, the payer is transferred to accounting as
the customer and the sold-to party is transferred as the branch office. If there is a branch
office/central relationship available in accounting, this is ignored.
 A: The sold-to party is transferred as the customer. If there is a branch/head office relationship in
financial accounting for this customer, this is taken into account.
 B: The payer is transferred as the customer. If there is a branch/head office relationship available
in accounting for the customer, this is taken into account.

If the credit limit check is active, the system reacts automatically as is described in the entry
"initial", regardless of what setting has been made.

Customer Number in the SD-FI Interface

When maintaining the billing type, you can use an indicator to determine whether the customer is copied
from business partner ‘payer’ or ‘sold-to party’ into field ‘customer’ in Financial Accounting.

The following settings can be made:

 No entry:

Customer (KUNNR) is payer, branch (FILKD) is sold-to party. The branch is only filled if there are
different customer numbers for partner functions ‘sold-to party’ and ‘payer’.

 A

Customer (KUNNR) is the sold-to party, branch is empty

 B

Customer (KUNNR) is the payer, branch is empty

s there a way to run VFK3 in background? When I execute the transaction the "execute in
background" option is greyed-out.

If you would like to run it in background,you have to use the program RVFAKSPE instead of
SDBLBDDL.   
  
There had been a change of the program used in transaction VFX3 for release 4.5B and
afterwards. You can see this in the System -> Status screen. The program used in releases up to
4.5B is RVFAKSPE, in releases after 4.6A it is SDBLBDDL. Report SDBLBDDL can't be used
for processing in the background, it is not designed to run as a batch job.

You can still process the release to accounting in background processing by creating background
jobs for program RVFAKSPE, which is still available.

Is there any T.code for finding the billing document was not released to accounting?

Please use Tcode VFX3

You can find the same against the following:

Sales organization*  
Mandatory 
Created by 
Created on 
SD document 
Billing type 
Billing category

While entering the billing document in vf01, you got the following information, how to
make it? 
The accounting document has not yet been created 
Message no. VF062

Go to release for accounting. However if it does not create automatically there will be a problem
posting to Finance. 

I would then suggest that you use t code VFX3 to release the billing document to Finance. There
is a log in both VF02 and VFX3 that will show what the error is.

First thing to do is re-checking the config for revenue account determination.

This is known in the IMG as "revenue account determination", but it covers a lot more than that
(discounts, taxes etc). This is what determines how the financial impact of your SD Billing
document is posted into the FI General Ledger. 

The integration is controlled both in SD and in FI.

In SD there is a awesome area of configuration called the pricing procedures. The pricing
procedure determines the final price quoted to the customer for a particular product. This could
be a complicated calculation taking into account the base price, any special prices or discounts
that may apply to that scenario, taxes, freight charges etc. These prices or charges are called
'condition types'. This condition technique is used in a number of areas of SAP.

For now all we need to know is that each condition type is assigned to an account key (or in the
case of rebates two account keys). You can assign multiple condition types to the same account
key. There are a number of account keys that are pre-defined in the system. For example:

- ERF freight revenues  

- ERL revenues  
- ERS sales deductions  
- EVV cash settlement  
- MWS sales tax 

Now we start getting to the integration by mapping the account keys to GL accounts. But it is not
as simple as that. It can be as flexible (ie: as complex) as you want. Start off with the most
simple approach. Generally if one is using a good sales / revenue reporting tool (eg: CO-PA)
then one does not need a lot of flexibility and variety in the GL accounts that are posted to. The
level of detail that you need in GL should be determined by your financial statement reporting
requirements - you may end up with only one Revenue account - it is a good bet!

So, taking the simple approach we would ignore most of the configuration possibilities :
procedures, access sequences, condition tables etc (Yes it is that 'condition technique' kicking in
again. Once you have worked through it once in one area and encounter it in another then
hopefully you will be comfortable in knowing that most of the standard configuration can be left
as is. ) 
We have to decide which access sequences we want to use (Five access sequences are defined in
the standard SAP R/3 System). To keep it simple, let us assume we just use one - for example:
the access sequence "chart of accounts/sales org./account keys".

The chart of accounts part is standard in all account determinations, so let us look at the rest.
This access sequence allows us to specify different GL accounts for different Sales
Organisations. 

Also check the customer master record for account assignment group.

4. Account determination
Now the sales order process is completed. Let's take a closer look at it from the accounting
perspective.

4.1. Document flow

You find the document flow from the menu Environment in every phase of the sales order
process. There also a button for it. The document flow looks slightly different depending on the
phase, but if you open it from the sales order, you will see all the phases and sub phases.

The document flow ties together all the documents of the sales process. Put the cursor on the line
and click on 'Display document' to open the document.
Accounting documents are created at the goods issue and billing. The text 'not cleared' beside
accounting document means that the invoice is not paid.

The integration points are following:

Sales order: the profit center is determined and copied to the following documents
Goods issue: posting to inventory and inventory change accounts.
Invoice: posting to revenue account, accounts receivable and tax accounts

4.2. Sales order

Move from the document flow to the sales order. Place the cursor on the Standard Order and
click the 'Display document'-button.

The sales order does not create any documents to accounting. However, some of the account
assignments are decided at this point. There are accounting relevant fields on both header and
item level. The item level fields are more relevant. The sales order items can be splitted into
different deliveries and invoices and the accounting information follows the items. Generally you
could say that the header level information is customer related and item level is product related.

Select the sales order line item and then menu Goto / Item / Account Assignment (or double
click the item row and open tab Account Assignment).
The profit center is defined at sales order level. Depending on the system settings the profit
center comes either from the material master (View: Sales:General/Plant) according to delivering
plant (transaction MM03) or from the Sales order substitution rules defined in profit center
accounting (transaction 0KEL). With these rules the profit center can be defined for example
according to sales organisation, product or customer characterics.

If no profit center is found and COPA is active, the dummy profit center is used. If COPA is not
active, the profit center is left empty and you will get an error situation in billing.

4.3. Goods issue posting

In the Document Flow place cursor on the GD goods issue: delvy document and click on
'Display document' -button. This takes you to the MM Material document.
The movement type for sales delivery is 601.

Click the accounting documents button.

A list of created accounting documents is shown. Click on the Accounting document.

In this example the goods issue posting looks like this.

The stock posting goes to a balance sheet account and the offsetting posting to inventory change
(P&L account).

The posting is created automatically at goods issue and the system has to find somewhere all the
necessary information for the posting. The accounts used are determined in MM automatic
account determination. The account assignments of the offsetting posting depend on the settings.

If the account is not defined as a cost element the posting goes to the profit center from the
material master.

If the account is a cost element, a cost object becomes mandatory. Usually the system looks for it
in the CO automatic account assigment table OKB9. In this example the cost assignment is a
profitability segmentand the posting rules are defined in COPA IMG.

4.4. Revenue Posting

Move from Document Flow to the billing document. Place cursor over Invoice and click on
'Display Document'.
In the invoice you can find accounting information from several places. There is a direct link to
accounting documents. The Accounting button lists all the accountig documents created. From
the Environment menu you find Account determination Analysis, which lets you analyze how
the account determination is made. On both header and item level you will also find lots of
accounting relevant data.

4.5. Account determination configuration

4.5.1. Goods issue - MM account determination

At goods issue the the owner of the goods changes and the stock change must be recorded. It is
posted in the balance sheet to the inventory account and the offsetting posting (cost) goes to a
profit an loss account Inventory changes.
Account assignments

The inventory account is a balance sheet account. In Profit center customizing you can define
wether you transfer the material stock balance to Profit Center Accounting periodically or on-
line. The profit center always comes from the material master according to the delivering plant
(tr. MM03, Sales: General/Plant).

The account assigments of the offsetting posting depend on how the account is defined. If the
inventory change account is not defined as a cost element, the posting goes to a profit center.
Here the profit center is copied from the sales order. It can come from a substitution rule or from
the material master.

If the account is defined as a cost element, it requires a cost assignment, which can be a cost
center, order or profitability segment. As the good issue posting is an automatic posting, the
system has to find the assignment automatically. It looks for the assignment in CO automatic
account assignment table OKB9. You can also define Automatic assignment to a COPA
profitability segment (COPA-IMG: PA transfer structures, tr. KEI2), which is the case here. .

Accounts

The accounts are defined in MM customizing under Valuation and account assignment. MM
account determination is not a 'straight forward -task. SAP has has made Wizard to assist in this.
Here I will only show you how to find the configurations for our example.
Start the 'Configure automatic postings under 'Account determination without the Wizard'. If you
get a pop up for missing account grouping code, press cancel. CLick the 'Simulation' button.

Enter the plant (1200), material number (R-1180) and movement type 601 Goods issue Delivery.
Press enter and then click the Account Assignments button.
On the simulation screen the system combines all the relevant information and shows the
accounts it has determined.

The MM account determination is based on transaction technique. In inventory postings there is

alwaus the transaction Inventory Posting (BSX). It defines the inventory account, which here is
310000. The system finds this account according to the transaction and valuation class of the
material.

The transaction for offsetting posting is GBB 'Offsetting entry for inventory'. This transaction
has an extra specifications called Account Modification key, which has a different meaning
depending on the procedure. The system finds this account according to the transaction, account
modification key and valuations class.

If you are interested on how the account determination works, SAP Press has published a book
about SAP Account determination. In book reviews you find my review of this book.

4.5.2.Billing - SD account determination

The accounting document created at SD billing contains typically following three lines:

- Customer posting in accounts reveivable and simultaneously posting to reconciliation

account in general ledger
- Sales revenue posting
- Tax posting
There can also be other accounts like discounts. Let's study the origin of these postings.

Customer line / reconciliation account

The first row in the posting is the customer line. It shows the customer number and makes an
open item posting to accounts receivable. At the same time it makes a posting in general ledger
to a reconciliation account. Double click the customer line and you can see the reconciliation
account.

The main rule is, that the reconliliation account comes from the paying customer's master data.

For special cases, it is possible to use an alternative reconciliation account. Settings for that can
be found in FI and SD customizing.

The reconciliation account is a balance sheet account and has no other account assignments.
However, you can transfer the posting to a profit center. This does not happen automatically. At
period end you must first Calculate Balance Sheet Readjustment in FI closing (tr. F.5D9 and then
transfer the postings in profit center accounting (tr. 1KEK).

Revenue posting

The setting for revenue account are defined in SD customizing.

In spite of the title 'revenue account determination', this is where the settings for all other
accounts are made as well.

Select option Assign G/L accounts.

SD account determination is based on condition techniques. The system reads the conditions
sequentially searching for a match. In this IDES case it will find the match on the second level in
condition CustomerAccountGroup/AccountKey.

Click on the second row.The table looks baffling, but is really is not that complicated.
In the first column you have the appilication. It is always V, which comes from the german word
for sales. Next you have a condition type. There are two alternatives. You choose KOFI, if the
posting goes to accounts that in CO are revenue elements (cost element types 11 and 12) and the
account assighment is profitablity segment (COPA) or profit center. This is usually the case for
revenues and discounts. KOFIK is used if you want to post to an account that is a cost element
(type 01) and the account assignment is cost center. In the third column you give the name of
your Chart of Accounts. In the fourth column enter the name of the Sales Organisation. In the
fift column you give the Account assginment group of the paying customer. Next comes the
Account assignment key. This is defined in SD customizing and is in SD pricing assigned to SD
conditions like sales price.

You don't anywhere define the company code in whose accounting the entry is made. This is
determined indirectly via the sales organisation, which is assigned to the company code.

The Account assignment groups for customers and materials are defined in SD IMG / Account
assignment/costing customizing under 'Check masterdata relevant for account assignment'.

Tax posting

The tax account determination is not done in SD. The account is taken from FI tax account
definitions. The tax account is a balance sheet account and has no account assigments.

Flow of Billing Document

Checking the Flow of Billing Documents

Use

You can use this function to compare the actual data in CO-PA to the corresponding postings
made in Financial Accounting (FI). This makes it possible to analyze the flow of values from
billing documents in Sales and Distribution (SD) to CO-PA and understand how any differences
arose between the different applications.
You can find this function in Customizing in the Tools ® Analysis section and in the application
menu under Tools ® Analyze Value Flows.

Functions

Values in billing documents are assigned to condition types in SD, accounts in FI and value
fields in CO-PA. This function shows you a list of the values posted in CO-PA value fields,
along with those posted in FI (profit and loss accounts) and SD (condition types). It also shows
any differences between the values in CO-PA and SD (Delta CO-PA/SD) and between SD and
FI (Delta SD/FI). If there is a difference, you can drill down to the respective billing documents.

Statistical condition types (that do not lead to accrual postings) are marked as such and are
included in the SD value. This makes it possible to compare the SD value with the CO-PA value.
Since these condition types do not lead to FI postings, their values are not taken into account in
the comparison between SD and FI. The delta between SD and FI therefore may not be the same
as the actual difference between the SD and FI values.

List Structure

The list is arranged in blocks, each of which contains logically related, hierarchically structured
information. Each block typically contains a value field, the condition types assigned to it, and
the profit and loss accounts linked to these condition types.

If two condition types post to the same account, they appear together with the corresponding
value fields and accounts in one block. At the top of this block, you see a separate total for all the
values in that block. Accounts that receive postings from more than one condition type are listed
separately again at the end of the block. Wherever possible, the system lists a CO-PA value, an
SD value and an FI value for each value field, condition type, or account.

The goods issue posting for a billing document is assigned to the condition type of the category
G (such as condition type VPRS). Condition types of this category are specially marked as such.
At the account level below condition types of the category G, you can see the accounts of the
goods issue postings, and any categories of billing documents that do not require a goods issue
are shown without an FI value.

Under Additional condition types you can find the following values:

* Condition types that are not assigned to a value field (the corresponding accounts appear under
Additional accounts)

* Non-statistical conditions that are not posted to an account with cost element type 11 or 12 are
not transferred to CO-PA.

Under Goods issue, you can see goods issue postings for which the billing document does not
contain a condition type of the category G.
For the purposes of reconciliation, two values are shown. These principally cause discrepancies
between CO-PA and FI. If you restrict the billing date in the selection screen (for example, to a
period),then the following values are displayed:

* Goods issue in earlier periods: These are the goods issue values for billing documents that have
a billing date falling within the selection interval but for which goods issue precedes the
selection interval. These values were therefore posted in CO-PA in the current period but were
posted in FI in an earlier period.

* Nonbilled goods issue: This applies to goods issue values that, firstly, have a goods issue date
falling within the selection interval, but, secondly, that were not billing at the end of the interval
(or were not billed at all). These values were therefore posted in FI but not until later in CO-PA,
if at all.

+/- Signs

The signs of the SD values are changed to match those of the CO-PA values so that you can
easily compare the values directly with one another.

The values for these SD condition types consequently need to have their signs reversed again
before they can be compared with the FI values. Any change in sign is shown at each level of the
hierarchy with a "+" or "-".

In some Customizing constellations it may not be possible to compare two hierarchical levels
that lie below the same level.