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 methodo 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 accounto 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 ordero 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 determinationNow 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 documentsGoods 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.