SAP BEST PRACTICE FINANCE PROCESS IN SHARED SERVICES

Procure to Purchase(P2P), Customer to Cash (C2C), General Accounting(GA)

Collected via SCN By: Ms.Pramila Nagaraj (Member in SCN since 2011 November to Present First Class MBA Finance Graduate (2009-10) Global Academy of Technology, Bangalore (VTU- Belgaum) Trained up in SAP FICO @ SAPTAC Bangalore (FRESHER)

©2012 SAP AG GERMANY – COPY RIGHTS OF SCN

©2012 SAP AG GERMANY – COPY RIGHTS OF SCN

Best Practise Finance Processes in Shared Services

This part will describe the best practise finance processes in a shared services environment. In the graph below it is visualized where the 3 concerned processes, accounts

payable, accounts receivable (incl. credit & collections) and general accounting can be found in the business process chain.

To find a definition of "best practice" finance processes is challenging. SAP defined as "best practice" these processes which are integrated best

in the [technical design].

Process cut in SSC environment:

All transaction bases finance processes have been analyzed in detail in order to define which process steps could be

migrated to a shared services environment. The dividing line between the local business unit and shared services

activities is referred to as a process cut. The clear description of the interfaces between the process cut and other parts of

the company is of crucial importance to the joint operations of the local units and the SSC. The guiding design principles for

defining the cut are the following:

Process steps at SSC: Process steps at local unit/country:

* Lower skill level

* Routine

* Transactional

* High Volumes

* Repetitive

* Low/Medium Risk

* Unique process steps

* Exceptional process steps

* Statutory requirements

* Customer facing steps

* Knowledge/Business transactional steps

* High skill level

* Medium/High Risk

Below we will go into more details on 3 main finance processes in the SSC:

Accounts Payable (AP/P2P), Accounts Receivable + Credit & Collections (joined to one process AR/C2C) and General Accounting (General Ledger, GA)

Accounts Payable / Procure to Pay (P2P)

1. Process Overview

2. Vendor Master Data Maintenance

3. Request to Receipt

4. Invoice Processing

5. Payment Process

6. Monitoring

7. Period Close

Accounts Receivable / Customer to Cash (C2C)

1. Process Overview

2. Customer Master Maintenance

3. Credit Control / Credit Management

4. Manual postings

5. Monitoring and Collection of Receivables

6. Bank reconciliation

7. Period end closing

8. Reporting

General Accounting (GA)

1. Process Overview (consolidated)

©2012 SAP AG GERMANY – COPY RIGHTS OF SCN

Accounts Payable-Procure to Pay (P2P)

Accounts Payable / Procure to Pay (P2P) Process Overview

The Accounts Payable / Procure to Pay (P2P) overall process covers the complete cycle from Vendor Master Maintenance through procurement and Vendor Invoice

Processing, the resulting Payment Processing to external vendors and the Period Closing Activities. All processes are accompanied by comprehensive and mature

monitoring to accomplish Sarbanes-Oxley Act (SOX) Compliance.

The Procure to Pay sub-processes covering Fixed Asset setup, capitalization and administration are not included in this process view.

Assumption for an effective P2P process:

The P2P process assumes that the following SAP modules are in place:

FI, AM, MM, PM (optionally for equipment master records).

The described Invoice Processing is designed as an SAP Business Workflow/SAP Webflow process including Optical Archiving for all incoming documents. Therefore a

scanning and optical archiving infrastructure needs to be in place to support the workflow functionality. The optical archive storage system needs to fulfill legal and tax

requirements to enable the storage of 'original documents'.

Accounts payable /P2P Process interfaces at SAP's SSC

It is interesting to see how different companies approach their AP process. The most common is a partially decentralized processing of AP, as it has developed over time.

This works as follows: companies keep invoices at the local subsidiaries and only the financial data get passed over to the SSC for processing. In order to minimize the

administrative effort of transferring paper invoices into electronic formats, more advanced companies have centralized the AP processing completely. In this case invoices

are sent to the SSC.

Below there is an example of the typical process cut for the AP/P2P process, with the SSC Interfaces for the SAP SSC:

As a prerequisite, a purchase order needs to be issued before actual purchases are made. This system entry allows an easier tracking of incoming invoices and allows an

efficient approval process. When goods arrive, a receiving clerk begins the process of quality and quantity check to assure that the goods delivered match the items and

quantities on the invoice. The invoice is scanned to be available electronically in the system.

Invoice Processing

Invoice processing

Invoice booking

The main sub-process in P2P is Invoice Processing.

In the SSC model all incoming vendor invoices are routed directly or indirectly (via courier) to the SSC, where further processing takes place.

The efficiency of the P2P process as well as the quality of the result is influenced by the quality of the purchase orders prepared outside the scope of the P2P process-

specifically the purchase orders which refers to services or deliveries spanning over multiple accounting periods. The purchase orders are therefore to be prepared with a

clear system indication of the relevant periods.

For processing incoming vendor invoices, also a workflow is in place to effectively serve the process and approval/control steps.

In this case the Incoming Invoice Verification Workflow is used.

At the picture below the main steps in the vendor invoice processing are presented:

©2012 SAP AG GERMANY – COPY RIGHTS OF SCN

As mentioned above, incoming invoices can be delivered to SSC in a direct or indirect way.

In most cases the address will remain in the local unit's country, but it will be replaced by a special predefined PO box address. The content of the PO box will be collected,

on agreed frequencies, by a courier, who will then bring the invoices to the SSC (direct way). When was chosen for the indirect forwarding, the invoices will have the regular

local address and will be received by local unit's postoffice, and there the unit itself will take care of the forwarding to the SSC.

When the invoices arrive at the SSC, first a dedicated scanning office clerk at the SSC will start evaluate in the bundle of invoices per local unit.

Three standard scenario's are applicable:

1. Received invoice states a valid PO (purchase order) number: these invoices can immediately be scanned with the specific scanning software (Ixos Econ Enterprise

Scan). Then the scans will be uploaded to the productive SAP ISP system, and the responsible P2P clerk working for the local unit will receive an invoice posting notification

in his personal ISP workplace inbox. From there the invoice will be posted using the PO ¹ as posting reference. Posting takes place in the module MM/LO. This posting

process is therefore relatively easy, because the purchase order carries the necessary information for the posting. After the posting is saved, the FI posting on the

vendor and cost accounts is made and the posting document will receive a payment block. Similar to the saving of the posting the system will generate an approval workflow

to the concerned PO requestor. When the approval is given, the payment block is automatically released on the invoice, and payment to the vendor can take place.

¹ Note: assumed is here that the PO details (amount etc.) matches the invoice.

2. Received invoice does not state a PO (purchase order), but the invoice is defined as 'exceptional invoice'. It therefore is not mandatory to have a PO stated on the invoice

and a PO will also not be created afterwards. The proceedings are similar to the way of posting described above (so starting from the scanning), except that the posting

itself will take place in the FI module, where all necessary posting data has to be filled in manually by the P2P clerk.

As above, after the posting is made/saved, the posting document will receive a payment block and the system will generate an approval workflow to the in the posting

(manually) entered cost center manager. When the approval is given, the payment block is automatically released on the invoice, and payment to the vendor can take place.

3. Received invoice does not state a PO (purchase order), and the invoice is not defined as 'exceptional invoice'. All the invoices are scanned and afterwards the SSC clerks

will use the Rejection Tool. Invoices and Rejection will be sent back to vendor via e-mail, fax or Original. In the workflow several rejection reasons and matching rejection

letters can be defined and chosen by the user. The data of the vendor will be merged into the rejection letter.

Furthermore the rejections (invoice amount etc.) are stored in the tool, which can be effective when for example preparing and proposing accruals.

Invoice storage/filing

Since the invoices are scanned, an electronic version of the item remains stored in the ISP system. Therefore there is no need to store original invoices. This,

however, depends on specific laws of the country for which the services are delivered.

In the case that the country's law requires a storage period for invoices, it will be agreed with the SSC that invoices will be send back to the local unit's office.

Monitoring

Monitoring

In order to secure the quality of the P2P process output, P2P clerks are responsible for checking and reporting the following items on a regular basis for and to the

concerned local units:

1. Vendors with a debit balance

Extract vendors which need to pay the company, instead of the company paying them. These

vendors will be dunned (sending of reminder letter) to address the due payment to them.

2. Items older than 4 weeks

Items older than four weeks have to be cleared by the P2P clerk: he/she contacts the designated approver of the invoice, investigates the reason for non-approval and

requests that the outstanding item should be cleared or rejected.

3. Items over specific amount/sensitive items

Here the check is on items booked over a specific value (for control reasons) and on specified sensitive items. Both the threshold and the sensitive items are agreed by the

local unit. Monthly a report on these items will be delivered from the SSC to the local unit F&A manager.

©2012 SAP AG GERMANY – COPY RIGHTS OF SCN

4. Double postings

SSC is running the duplicate analyzer. Two related documents are reviewed whether they represent two separate instances. When an actual double posting is found, one of

the documents is blocked for payment. If both have already been paid, the amount is claimed by the P2P clerk back from the vendor.

5. Deleted workflow items

Deleted items out of the invoice verification workflow described in chapter 3. These deletions must have a reason stated in the system; for control purposes.

6. Asset acquisitions

Check 5% of assets (at least 5 assets): whether it should b class 1020 (Low Value Asset), correctness of asset class, net amount per one piece.

7. Asset retirements (sales, scrapping)

Check 5% of assets (at least 5 assets): whether signed sales documentation is attached, profit/loss on retirement, customer name.

8. Asset transfers (Intercompany)

Check 5% of assets (at least 5 assets): whether the transfer was correct. Report is typically empty.

9. Assets with goods receipt, without invoice receipt

On the day when depreciation run is done: Run the report again.

10. Asset-related costs in P&L

Verify 5% of postings (at least 5 postings) whether it was really an expense, or whether it should posted as asset.

11. Check blocked vendors with open items - weekly before payment proposal

Follow up with local F&A/HR-Payroll on open items. If they agree with payment, vendor has to be unblocked by VMD team before payment.

12. Check vendors marked for deletion with open items - weekly before payment proposal

Same as previous report

13. Asset master records with blocked cost centers, profit centers and internal orders

Load variant "SSC", which contains all company codes migrated to BSCE.

14. Run report on Dummy assets; create asset master records - weekly

Create asset master records for purchase orders that are in the result of the report.

15. Check invoices posted incorrectly with future invoice date

Payment Process

Payment process

When an invoice has been released for payment (e.g. after the approval in the invoice booking process) it can be paid-out to the vendor.

As a standard a Shared Service Center will make outgoing payment runs with a fixed schedule. In most cases there will be a weekly payment run. Besides standard

payment runs, the SSC also has an option for an exceptional payment run, where urgent items on request can be paid out immediately.

The description below is based on a standard payment run:

Standard payment types included in a payment run can be: Vendor invoices, Customer reimbursements, Netting items and Intercompany payments.

Normally payment types as Tax payments, Salary payments, Cheques are not part of the A/P payment run due to their country local dependency or sensitivity.

Step 1: The P2P clerk starts the payment program (transaction F110). The 'run date' is entered and by entering parameters, specific filters can be set on the full payment

range. As standard all vendors will be chosen as a range, so that every applicable document will be included in the run.

After this the clerk is able to produce a payment proposal list. Firstly, this list has to be verified/approved by the local unit. In this step individual payments can still be altered.

Step 2: After payments have been reviewed, possibly altered, and eventually approved by the local unit, the P2P clerk can execute the actual payment run. At the same

time actual FI payment documents (KZ type) are booked (Vendor <-> Bank).

Step 3: The P2P clerk uploads the payment documents created by the payment run (KZ, number range) into the online payment tool in ISP (this is a different

tool compared to transaction F110!).

After upload the tool creates/sends ISP work items to defined payment approvers in the local unit. These users are authorized to sign payment orders for their bank.

In the work item the local payment authorizer enters the tool via a hyperlink in the item and has the possibility to review, to analyse and eventually to approve the payment

documents with a digital signature. Two digital signatures are required before a payment document can be sent to the bank. Whenever a second signature has been set to

the payment document(s), the tool sends the payment order to the connected bank (via an online connection), which then executes the actual payment.

Step 4: As last step, the tool (automated) will send out payment advises by email to the payment receivers. This only happens in case this email address is maintained in

the master record from the concerned receiver (e.g. vendor master record). After these steps the P2P clerk will archive the payment list from this run and by this step the

process is finished.

Period Close

Period Close

Closing guidelines and timeline will be communicated for every month-end closing and year-end closing by Corporate Finance Reporting (CFR) to both the local unit F&A

responsible as to the SSC clerks. Both teams have a joined task to bring each closing to a timely and successful one.

- Prepare and post accruals

At the end of each period we need to make sure that all expenses are booked for all goods and services delivered. For invoices not yet received/booked there is therefore a

need to reflect these in the financial statements.

Bases on inputs such as invoices from the rejected invoice workflow, expectations from local departments such as marketing, checking of accrual relevant accounts, and

future obligations extracted from "open purchase order reports". There are as well some accruals for Parked items and rejection invoices. The basis of these accruals are

©2012 SAP AG GERMANY – COPY RIGHTS OF SCN

coming from ISP standard report run by SSC clerk and this proposal is then sent to the local unit's responsible for approval and review.

After approval the local unit will request to General Accounting team (see process GA) at the SSC via a posting template to book the final accrual amount(s).

- Reconcile (settle/clear) transitory accounts

At the end of each period there is a need to reconcile transitory accounts, such as intercompany transitory accounts. In this case the SSC-clerk checks if the

accounts' balance is zero. If this is not the case, the clerk contacts the respective person at the concerned subsidiary from where the booking is missing. He or she needs

then to instruct either their local or SSC responsible clerk to make the missing posting.

The missing invoices/goods receipt accounts are also checked. On the day of period-end closing, the SSC clerk prepares an account statement and checks whether the

balance of the goods receipt account is equal to zero. The list of missing invoices is printed. If necessary, the local purchasing department is contacted in order to obtain the

missing invoices.

- Reconcile vendor accounts

Depending on the Service Level Agreement with the local unit, the SSC clerk sends reconciliation statements to vendors. A possible agreement could be for example: The

top 10 vendors are reconciled every month and all vendors are reconciled once a year.

The SSC clerk examines the reply sent back by the vendors. In case the reply agrees with the ISP system account balance, the process ends here. In case of a mismatch,

for example due to a missing invoice they contact the vendor in order to obtain a copy of the concerned document. The document can then be processed in the invoice

booking process described earlier. If the mismatch reason is an improper posting by SSC, the AP clerk reverses the improper entry. Then the original invoice is routed back

into the regular invoice processing workflow.

It is possible that the vendor itself sends the SSC a reconciliation statement. The activities are then similar to described above. In case there is a match of balance, checked

by the SSC clerk, the local unit's responsible for A/P will sign the vendors reconciliation statement, which is then sent back to the vendor.

If the statement mismatches, the SSC clerk fills out a mismatch report and/or prints a separate account statement from the ISP-System and sends it to the vendor/auditors.

- Provide audit support/prepare country specific reports

In period-end closing activities the SSC-A/P team provides support for the local unit, in ways like creating and sending out vendor reconciliation letters (in most cases this is

a year-end activity).

Request to Receipt

Request to Receipt

The process 'Request to Receipt' covers the procurement activities within local organizations. The responsibility for this process stays with the local units and the Global

Purchasing Organization (GPO). Based on the requirements by the different Lines of Business (LOB) goods or services are ordered via the Enterprise Buyer Professional

(EBP) system or directly using the ERP system. A requestor expresses his needs to the Purchasing department that contacts the conerned suppliers for different bids. After

the bid selection, a shopping cart is created by the Purchaser. Once it has been approved by the manager's cost center or the Managing Director, the shopping cart os

transformed into a purchase order that is sent to the supplier.

Once the service or the goods are delivered the purchaser validates the good receipt to launch the payment bill.

Sarbanes-Oxley Act

Sarbanes-Oxley Act

The Sarbanes-Oxley Act (SOX), one of the most significant corporate governance-related legislation enacted in the United States in decades, passed into law in 2002 in

response to recent and prominent corporate failures, such as Enron, Worldcom, among others.

Due to SAP's listing on the New York Stock Exchange (NYSE), the Act applies to SAP, and stipulates extensive requirements for corporations in the areas of public

disclosures and internal governance procedures.

As one of the core requirements linking companies' internal governance structures with their external disclosure obligations, the Act requires a company's CEO and CFO to

provide a certification along with each of its filings of quarterly results stating that both officers have reviewed the company's Internal Controls systems and processes

(including key controls such as segregation of duties, dual control processes, automatic system checks, and so on) embedded in a company's business processes. On the

threat of harsh penalties of up to U.S. $ 5 million fines or up to 20 years imprisonment for wrongful certifications, the CEO and CFO must find their company's internal

controls to be active and effective in providing reasonable assurance to avoid misleading or wrongful disclosures as well as ensure efficient business operations.

©2012 SAP AG GERMANY – COPY RIGHTS OF SCN

Vendor Master Data Maintenance

Vendor Master Data Set-up/Maintenance

The process 'Vendor Master Data Set-up/Maintenance' includes activities of requesting a new vendor or vendor changes, processing the committed data and the SOX

compliant approval of all changes. The final product - updated or new vendor master record - is used for procurement and Accounts Payable purposes. Technically the

described process is implemented as an SAP Business Workflow started by a WEB Dynpro to enter the request data as an Employee Self Service Scenario. Attached

documentation (vendor letters, legal/taxforms) are optical archived and linked to the vendor master.

1. The request for a vendor set-up is triggered by the local entity based on procurement needs. The requesting party could

either be a centralized purchasing unit, which decided to purchase goods or services from the new vendor, or a

decentralized unit within the organization responsible for specific procurement types (e.g. Consulting Department in

special need for a 3rd Party Consultant on a customer project). Requesting a vendor change is also very commonly

done by the Accounting Department within the Shared Service Center based on new information given on vendor

invoices (e.g. new bank information, new address information). For this specific case the vendor change request step is

integrated into the 'Invoice Processing' described in chapter 3.

The requestor uses an electronic form to enter the vendor information. The online form validates already the entered

information against the data base of the global vendor management system within the ERP system. Using this

advanced search functionality multiple vendor masters are avoided. The company code depends on customizing of the

workflow process and enables the fullfilling of local legal and tax requirements by setting fields as mandatory for input

and adding company specific fields.

The requestor is able to attach conducting information (e.g. signed vendor letter with bank information, global/regional

master contract) as scanned documents or PDF. All attached documents are optically archived and therefore non-

changeable to fullfill SOX requirements.

2. Once the request is saved, the Workflow is triggered sending a control and approval step to the Global Purchasing

Organization (GPO) unit responsible for the new vendor. This GPO unit can either be located in the BSCE or within the

local entity. GPO is responsible for analysing the request from a procurement and global purchasing strategy to either

accept the company as a new vendor or to recommend an existing vendor. In case the request was triggered by the

responsible GPO, the approval step is skipped automatically.

If the request is rejected in this step, the information including the rejection reason, is sent back to the requestor. The

requestor can either delete or restart the request with additional information.

3. Approved by GPO the Workflow triggers an action item to the Vendor Master Data Team within the BSCE. Completed

with data base search data evaluating equal or similar existing vendors the request data can be used to create a new

vendor or to extend an existing vendor to a new company code. In addition, the BSCE controls the documentation

requirements (e.g. original vendor letter) and completes the data from the accounting view.

After saving the updated and approved information the vendor is created in the system, but blocked for posting and

payment. At this point of time GPO can start to issue Purchase Orders on the vendor account.

If the request is rejected in this step, the information including the rejection reason is sent back to the requestor. The

requestor can either delete or restart the request with additional information.

4. After the vendor creation an additional 'SOX Approval' guarantees SOX compliance of the process. All saved

information is compared with the request information and the original document delivered by the vendor. If the

whole information can be verified, the approval unblocks the vendor account for posting or outgoing payments.

5. The vendor is activated for all accounting activities. Automatic mail information is sent out to the requestor including the

vendor account number.

Processing of a vendor set-up or a vendor change are very similar due to the business critical information in the Vendor Master Data. Changes in SOX relevant data (e.g.

bank information) are therefore also subject of the full approval process.

http://wiki.sdn.sap.com/wiki/display/SSC/Accounts+Payable-Procure+to+Pay+(P2P)

©2012 SAP AG GERMANY – COPY RIGHTS OF SCN

Accounts Receivable-Customer to Cash (C2C)

Accounts Receivable/ Customer to Cash (C2C) Process Overview

Accounts receivable (AR)/Customer-to-Cash (C2C) is the second most often-deployed process by SSCs. Companies generally keep AR inside the company

because a close relationship to its customers is often considered a company's most important asset.

The process covers the area from Customer Master creation, through Collection, Dispute and Dunning Management to eventually booking of incoming payments of

customers. Furthermore it covers the area of daily bank reconciliation (incoming and outgoing mutations on banks/bank statements) plus invoice creation (invoices other

then standard billing).

For the activities monitoring and period close activities are also performed.

Assumption for an effective C2C process

The C2C process assumes that the following SAP modules are in place:

FI, dispute management, BW, FIS Reporting.

One of the main assumption for the Customer-to-Cash process is that the Dispute Management Tool (DM) is rolled out (both in the local unit as in the SSC).

Furthermore the C2C process largely depends on their clerks abilities and skills to understand and handle customer-payment cases. It is therefore one of the few processes

in the SSC which requires excellent local language skills.

SSC Interfaces:

The SSC takes over the processing of customer orders as soon as the goods have been sent to the customer and the appropriate posting has been made to the AR system.

The processing clerk checks that all ordered items have been shipped and then issues an invoice. The issueing of invoices at SAP is however done by the various billing

departments (e.g. Consulting Billing, Education Billing, Software & Maintenance Billing). Occasionally the A/R / C2C department at the SAP SSC will issue invoices for

"other" billing types, such as for example marketing invoices.

The main focus for the Accounts Receivable / Customer to Cash(C2C) process within SAP SSC is the monitoring and collection of the outstanding receivables. The

collection efforts/responsibilities are in this case shared by two platforms: The SSC C2C clerks are responsible for first level collection activities, as for the local unit is

handling the 2nd level collection activities. Main indicator for the split is the dunning level of the receivables/open items.

The second main task is the daily review and reconciliation of the bank statements/incoming payments and the matching of the outstanding invoices.

One of the most important bottlenecks for an perfect cash-inflow (or in other words "non-payments & deductions") is the excistence of customer disputes.

The clerks working in this process will get informed about these disputes from different area's (eg their own contacts with customers, or from internal departments, or from

external sources). For managing this challenge a dispute management tool is in place to effectively register, follow up and monitor on the dispute cases.

Below is an example of the typical process cut for the AR/C2C process, with the SSC Interfaces for the SAP SSC:

Bank reconciliation

Bank reconciliation

The A/R department in the SSC also processes the daily bank-statements / -mutations for the local units.

All bank-mutations are delivered from the connected banks in electronic format to SAP.

The central treasury department at SAP's headquarter creates from these electronic bank statements, on daily basis, batch-input-sessions for posting the items on the bank

transitory accounts and clearing/posting open items on sub ledger accounts.

©2012 SAP AG GERMANY – COPY RIGHTS OF SCN

Fig 9 - Corporate Treasury

The electronic bank statements are now also available and viewable in the ISP system.

For practical reasons and for further processing most clerks will open up a screen with the new statement of the day and continue with steps below.

Clearing of bank transitory accounts (11XXX1 to 11XXX9) is performed with the automatic clearing program by the SSC. With this program the batch input sessions are

being processed, and for every bank mutation on the processed bankstatement the system will automatically go look for "matching data" in the mutation line item. Most

commonly it looks for invoice numbers. But it can also search for other indicators like "bank costs". Whenever an indicator, such as invoice number is found, an automatic

posting is created (customer payment in this case) which clears the open item found on the customer. This process takes place in background mode, so the clerk will not

see, or manual has to interact to create these postings. Whenever there is no link found one of the statements mutation lines, the batch processing halts, and the clerk has

the option to manual interact and search for the matching open items, by for example:

- analysing bank statement once more; sometimes invoice numbers are only halfway written in the mutation line, or invoice numbers are written joined together

- contacting the customer, if no invoice info is available

- match the payment with an earlier received written payment advise

Basically the manual interaction in the batch input processing allows the clerk to show the batch input which items needs to be cleared in the concerned bank mutation, save

it, and then the batch input processing continues with the rest of the mutation lines on the statement.

Another possibility is to "skip" the halted transaction. Then still the batch input processing continues, but the payment posting for the mutation is not made. The clerk has

then at a later point in time the possibility to fully manually create payment and clear that item on the transitory account.

The batch input processing will also process the clearing of outgoing payment documents (automatically posted by the payment run -> See accounts payable process).

These mutations are matched easier, since all info/details are already set by the same system. Only manual interaction could occure for example when there is occurance

of currency difference, and therefore the actual currency exchange rate on bank statement could differ for the currency rate in the payment document in the system.

If due to whatever reason a posting is not possible immediately (missing references /short payment /payment for other customer items as well ...), the posting should be

done to one of the "special" (internal) G/L transitory accounts. (So called dummy accounts; these accounts replace the main bank transitory accounts, since these last ones

need to be cleared in the morning, to full extend for old items).

To make this happen the clerk uses a special reposting program in the ISP system, which automatically "reposts" remaining un cleared items to the respective special G/L

transitory accounts.

The clerks have then more time available to investigate in these remaining items in order to clear them as well, as described above in manual clearing mode.

The reason for this reposting is that the main transitory bank accounts need to be cleared every morning due to cash pooling purposes.

The effectiveness of the bank-batch input process highly depends on the content-quality of the electronic bank-statement data. Therefore regular interaction/alignment

between global treasuries, A/R responsible and customers is necessary in order to reach the goal of high quality data.

Credit Control

Credit Control / Credit Management

This process, containing activities such as credit risk analysis, solvency analysis and customer credit status evaluations and setting credit limits is handled fully at the

serviced local units.

The credit control / credit management process focuses is basic on risk analysis for existing customers, as well as potential new customers. A review of the credit risk is

done in the case of problem accounts, press coverage causing concern, or prior to major impending contracts.

There is little to no impact with the SSC AR/C2C process; the only direct link is with the collection process, where credit control can impact the way a customer is collected.

(When for example a credit limit has been set for a customer).

Customer Master Maintenance

Customer Master Data Set-up/Maintenance

Customer master data records are containing all specific data related to a specific customer such as name, address, telephone, bank details, sales related data, standard

payment terms, contact persons etc.

The records will be created and maintained exclusively by the local organisation due to the fact that several departments have varying requirements towards this master

data.

©2012 SAP AG GERMANY – COPY RIGHTS OF SCN

Although this process in handling stays completely in the responsibility of the local unit, there is still a small interaction between the SSC and the local unit;

Whenever there is a customer contact with the SSC, which delivers info on a change in the customer master data, the SSC will start a "customer master data change"

workflow which is re-routed to the local unit's responsible person. Changes in the master especially for changes in the bank details (can be necessary for refunding of credit

amounts). The eventual mutations will, as said, be handled at the local unit.

Another occurrence could be that the customer informs the SSC about changes in the address data, or name. These info-types are directly forwarded to the local unit (e.g.

by mail) for further processing.

Manual postings

Manual postings

Manual postings in the C2C/Accounts Receivable process refer to invoice posting, credit note posting, intercompany posting (non-CBAC), repayments and instalment plans.

With regard to invoice posting: in this case C2C only creates invoices which are not part of the standard billing.

There are the following types of manual postings:

- Marketing, special event invoices

- Other exceptions (no reference to daily business)

- Special customer credit notes (discounts)

- Intercompany postings

- Repayments

- Instalment plans

Note: The documentation for all manual postings is scanned in and the image is attached to the posting.

Below we will go into little more detail for two types of manual postings.

Repayments

A repayment is a refund of a credit amount to the customer. Repayments can occur in situations where, for example there is only one credit note remaining on the customer

balance. Parties can agree that the credit amount is payed out to the customer or that they will wait for future invoices to settle the credit amount. In case the agreement is

that the credit amount will be paid out, the C2C clerk will ask an official written request (fax/email/letter) from the customer, where they will state the payment details, such

as the necessary bank information. The clerk will then fill in a specially designed "repayment form", which states the details of the repayment, and the reason. This form plus

the customer request will then be signed by the SSC C2C manager and after 1st signature forwarded to the local unit's responsible. After his/her approval, the form is send

back to the C2C recruit, who will then remove the payment block from the concerned items on the customer account. Last step is that the C2C clerk will instruct the P2P

department in the SSC to include the specific customer in the next payment run. The P2P clerk will then add the customer number(s) in the next payment run and the

amount will automatically be paid out (for payment run details, please refer to the P2P process)

Instalment plans

A customer calls the contact person, for example after receiving reminders, in order to inform SAP about his liquidity issue and to request an instalment plan (payment of the

due amount in terms). The issue is noted and forwarded to the responsible person at the local department. At the local unit an investigation for the proposal will start

(credit/risk check, info from internal resources such as sales/consulting etc.).

The decision whether an instalment plan is possible or not can be based on the following questions:

- Is the liquidity problem temporary?

- Is the customer solvent enough to fulfil the instalment payments?

- Do extraordinary financial difficulties exist?

- Liquidity inquiry at credit databank; such as creditreform/dun and bradstreet.

At the end of this investigation the local department lets the final payment plan proposal verify and sign by the F&A manager. The signed instalment plan, along with a letter

concerning all customer duties about payments, is sent to the customer for notice and approval by the local department in charge. The customer is requested to confirm the

plan in one week time. The final customers confirmation should then be scanned and attached to the customer master data.

The individual instalment amounts are created in the ISP by transaction code F-30. In other words: the original due amount will be replaced by splitted amounts/instalments

with separate due dates (e.g. 100 000 EUR will be replaced by 4 installments of 25.000 EUR each, with separate due dates). Each pending payment is treated like an open

item. Therefore the local responsible person adds detailed text to the open items (see 'adding text to open items') with information about the instalment plan. This info is

then passed on to the SSC A/R team per e-mail or fax. The Open Item Management process (see Monitoring & collections of Receivables) follows the case accordingly. At

the same time the case will be supervised by the responsible specialist at the local unit and will be escalated to the legal department, if no payment for the instalments, has

been received on time.

Monitoring and Collection of Receivables

Monitoring and collections of Receivables

The process of monitoring and collections of receivables can be defined as the leading/most important process within the Accounts Receivable/C2C process.

In the timeline from invoice creation to payment several instances can occur which can block the natural "flow to payment". Easier said: When an invoice has been created

and the receivable is booked into the system is it expected to be paid within the standard payment terms of a company. Thus when standard payment terms are "30 days

nett", ideally invoices will be paid 30 days after the invoice date. However, this is in most cases far from reality.... There are several "challenges" to overcome, which block

the "flow to payment" :

©2012 SAP AG GERMANY – COPY RIGHTS OF SCN

Fig 1 - C2C Challenges

Main goal of monitoring and collection is to get a firm grip on these challenges. This can be reached by implementing effective tools and collection methods, plus having the

skilled A/R personnel who are able to handle collection cases almost as a "second nature".

Collections

There are 3 main subprocesses defined within monitoring & collections:

Fig 2 - Monitoring and collections of A/R

Below we will go into more details of the 3 sub-processes:

Open Item Management

Dunning

Dispute Management

Open Item Management

Open Item Management

Basically the sub process "Open Item Management" is the leading sub process, where Dunning and Dispute Management are more parallel processes to the first

mentioned. Open Item Management's main objective is to obtain, in the most early stage of time where invoices have passed the agreed payment date (payment terms), the

information/reason for non-payment within the contractual agreed terms. The information gathering is mainly done by making calls, sending emails/ letters (e.g. dunning

letters) or being informed by other sources (e.g. internal sources like sales/commercial departments, or external sources; newspapers/internet etc.).

Best way to make the basic approach of Open Item Management visible is again a graphic:

©2012 SAP AG GERMANY – COPY RIGHTS OF SCN

The starting point is of course the invoice/receivable booked on to the customer.

In some cases countries have decided to implement a por-active collection approach by contacting a customer before it is due when 1) the payment term of an invoice

largely exceeds the companies standard payment terms (exceptional payment terms) or when an invoice is considered as a "big amount invoice" (threshold determined by

the local unit). In both ways possible "non-payment" issues for these specific, risk sensitive invoices can be discovered in a much earlier stage.

For all other standard invoices, an A/R clerk place contact when the due date has passed.

In this contact the customer can basicly inform the A/R clerk about following status:

- The invoice is not known/not booked; The customer requests an invoice copy

- The invoice is known/booked, but still needs approval at customers side before it can be paid out

- The invoice is known/booked and approved and will be paid; The A/R clerk will ask about the exact payment date

- The invoice is known, but the customers informs the A/R clerk that they have liquidity issues, and can therefore not pay the invoice (yet)

- The invoice is known, but the customers informs the A/R clerk that content wise the invoice is not correct and needs to be re-issued (e.g. wrong address, wrong VAT

amount, missing PO nr. -> see Dispute Management chapter - billing issues

- The invoice is known, but the customers informs the A/R clerk that the goods/services received are disputed, and therefore the concerned invoice is blocked for payment.

See Dispute Management chapter - Commercial issues

Most common selection approaches are:

1. Investigate major items: The SSC A/R clerk selects items, for which he or she is responsible and sorts the A/R current column looking for any customer whose balance is

above a certain limit.

2. Investigate historically critical items: Identified customer accounts which had payment problems in the past and require special attention.

3. Investigate dunning keys: Dunning key is currently used as a "status indicator" for an invoice. Basically every collection activity performed by and A/R clerk gives the

concerned open item a new "due" status. One of these could be for example a "promise to pay" from a customer. Or another: "invoice is part of a payment plan". An A/R

clerk has the option, through the worklist shown above to navigate/drill down onto dunning key level, and therefore focus on specific groups of invoices and follow up on

their current due status.

©2012 SAP AG GERMANY – COPY RIGHTS OF SCN

One other very important aspect of the A/R process 'collections' in the SSC environment is the information sharing.

Therefore all A/R clerks maintain detailed logging info directly into the system.

Whenever there is info available, or contact with a customer has been made, this is logged and/or linked to the concerned open items in the system. So in other words,

faxes, emails, customer-call details are all stored "behind" the concerned open items in the system.

In this way all parties working on receivables (SSC + local unit) have the same/one info-source.

Dunning

Parallel to the basic collection process the A/R clerks use dunning for addressing overdue payment to customers. For this they use the dunning run in ISP; With this tool the

A/R clerk is able to send predefined dunning letters, which the tool generated for due invoices, bases on pre-set dunning frequently. An example can be: Every invoice

which is due 7 days receives a 1st dunning letter, every invoice which is 14 days due receives a 2nd dunning letter, and invoices due more then 35 days receive a final/last

dunning letter (3 dunning letters in total is assumed as a standard). This frequency is not something standard. The frequency is something up to the local decision.

The A/R clerk in the SSC will fully run the dunning process: first he/she will create a dunning proposal list (automatically created by the dunning tool) for all open items

existing on the run-date. The proposal list is then checked and altered/approved or directly approved by the local unit's responsible. After the approval the dunning run is

finalized by executing the dunning itself. The tool will now create a "print-spool" with the various dunning letters, which are the printed out and send to the customers directly

from the SSC. The dunning process in the SSC environment is in our case leading for pointing out (collection) responsibility for A/R open items. This is defined as: open

items which have dunning level 1 and 2 (so items which received a 1st or 2nd dunning letter) are collection responsibility of the A/R SSC clerks; items with 3rd level are

handed over in collection responsibility to the local A/R unit.

Dispute Management

Dispute Management

The 3rd sub-process in monitoring & collections is called Dispute Management. This is the area where all disputed invoices are monitored, forewarded to the responsible

persons, and followed up.

There is sometimes un clarity about what exactly the definition of a dispute is.

Here it is defined as a reason from the customer’s side for not accepting (and therefore paying) an invoice/due amount because of the following main reasons:

1. Invoicing/formal issue

The received invoice(s) is/are content wise not correct: This means that there is a content; error on the invoice; this can be, for example, a wrong address, wrong contact

person, missing purchase order nr etc. In most cases a new invoice has to be created and the old one will be credited.

2. Commercial issue

The received goods/services are disputed. Therefore the invoices for these deliveries are blocked for payment until the issue is solved. The involvement of commercial

colleagues is necessary to solve these issues.

Information on disputed invoices can be received from several sources within a company. The two main areas will be the A/R C2C area (where there is direct contact about

open invoices) and the billing area (from where the invoices are created and send out; a customer can for example contact the billing creator directly after receiving the

invoice).

©2012 SAP AG GERMANY – COPY RIGHTS OF SCN

Other areas like commercial/sales departments also often have valuable information on disputed (sometimes even before an invoice is created).

Because of this, it is necessary to control and record these inputs in an efficient way.

The A/R area is using the Dispute Management tool (see details) in order to get a grip on disputed invoices.

Whenever there is info available about disputes, a dispute case will be created by either A/R clerks or billing clerks in the SSC. The disputes can be created directly from

ISP/open item concerned, or in the dispute tool itself (then linking the concerned documents later in the case creation).

In the to-be created dispute case the creator will insert:

- a dispute 'Coordinator'; this is the person who creates and monitors the dispute

- a dispute 'Responsible'; this is the person who is responsible that the dispute will be solved within expected quality and on expected time

- a dispute 'Processor'; this is a person responsible for authorizing credit notes, delivering information to resolve the case, carry out single actions (e.g. create credit notes,

new invoice etc.)

Furthermore the 'dispute reason' is inserted (indicators for several dispute reasons, extracted from the two main area's - invoice issue - and - commercial issue, can be

selected via a pull-down menu).

Also all possible details on the dispute is logged/linked into the newly created case. After creation the dispute case is forwarded by workflow to the "dispute responsible"

who is then asked to follow up on the case.

The dispute tool is real time connected to the ISP system. When the case is saved the concerned open items will get a dunning block, a case ID and the indicator (dispute

indicator will be linked to the dunning keys, described earlier). Due to the dunning block and indicator, in collections the concerned items are basically blocked for standard

collection contact such as dunning letters and/or calls/emails etc. Therefore it is important that all responsible departments involved in solving disputes, such as billing

departments for invoicing issues, and commercial departments for commercial issues are working in a most effective and active way to come to a quick resolution of existing

disputes. Solving disputes is one of the key factors for improving the company’s customer satisfaction.

Period end closing

Period End Closing

For the C2C/Accounts Receivable process the period end closing is a minor task; the information can come from Local or SSC but the validation is coming from the local

side:

- Specific bad debts postings :

Customer specific reserves for amounts deemed uncollectible due to the fact that the customer is suffering from financial distress, insolvency, has filed for bankruptcy or

similar cases.

- Sales allowance postings :

Customer specific allowance for amounts that are likely to be credited due to the customers dissatisfaction with our products or services

©2012 SAP AG GERMANY – COPY RIGHTS OF SCN

Reporting

Reporting

On a monthly basis the SSC A/R Clerk will create and send out a "CFO reporting package" to the respective CFO/F&A manager of the local units.

The package consists of the following reports:

- A/R balances (due/not due)/divided into business units.

- Invoices/customers with dunning blocks.

- Overview of booked sales allowances/specific bad debts per concerned customers.

- Days of Sales Outstanding (DSO) development past 6 months. (Details of the DSO figure can be found below)

____________________________________________________________________________________________________________

DSO = Days Sales Outstanding

What is DSO ?

The DSO is the number of days it takes on average to collect receivables.

Or alternatively, it is a measurement of the number of days worth of average sales that the A/R represent.

The DSO is a useful benchmarking tool, allowing comparison of accounts receivable and the collection thereof

between countries/local units based on rolling averages. The rolling average smoothes the seasonal variations, and

allows to calculate a value every month that can more readily be compared to previous months.

DSO@SAP is based on average A/R and average sales of last 12 months.

Additionally there is a DSO overdue which is a measurement of the number of days worth of average sales that the A/R overdue represent.

What does DSO indicate ?

A high DSO figure can indicate the following:

Poor collection

Problems with the product -customers not paying because they are dissatisfied (disputes)

Extended credit terms extended customers

Poor quality of clients / payment behaviour

Poor management

Lack of follow-up on disputes

Depressed economic climate

For what can the DSO figure be used ?

DSO can be used for the following:

Collection efficiency indicator

Comparison to other countries/local units, industry and other companies.

Comparison of payment terms granted (more extended terms means higher risk)

For use in cash cycle management - look at it whilst also considering days payables outstanding and other cash measures etc.

Use as an indicative measure for forecasting & planning purposes.

Can be used as a trend analysis. By doing so special effects have to be considered, e.g. high bad dept for specific customers.

How is the DSO figure calculated?

On average the rule is that the DSO should not exceed one third to a half of the selling terms (therefore selling terms of 30 days should ideally have a DSO not exceeding

45 days).

©2012 SAP AG GERMANY – COPY RIGHTS OF SCN

General Accounting (GA)

The General Accounting process

The General Accounting (GA) process combines all processes that are related to the closing of the financial books as well as other procedures and process steps that are

related to other Finance & Accounting activities. In the picture below the general accounting sub-processes and activities are described as they are handled by SAP's SSC

(or in combo with the serviced local organization). For all period end closing activities the main control goes to SSC and end responsibil ities are remaining at the local

organisation. The SSC provides on bases of local instructions transactional closing activities or automatic transactional closing activities without instructions (which is then

part of the agreement between parties).

The General Accounting process is divided into the following main sub-processes:

- Period End Procedures (1)

- Bank Postings and Reconciliation (2)

- VAT Management (3)

- Consolidation, Tax and Audit (4)

- Other General Accounting activities (5)

1. Period End Procedures contain all activities to collect, review, and reconcile all information to prepare the financial statements.

2. The Bank Posting and reconciliation process contains the posting of the Global Cash Pooling as well as Inter-Bank Transfers. Main parts of the Bank Posting and

reconciliation process are covered by the C2C process.

3. The VAT Management process is related to all activities related to VAT e.g. checking VAT postings or preparing VAT return.

4. Consolidation, Tax, and Audit related procedures usually contain the preparation of special information needed for Consolidation purposes or to prepare the Audit on the

Financial Statements or a Tax Review by the Tax authorities.

5. The Process Other General Accounting Activities cover all procedures related to Finance and Accounting issues that are not covered by the processes described above.

In basic the general accounting clerk will process his/her task on scheduled times (according to a corporate timetable); in some occurrences independent from the serviced

local unit, and in other occurrences with (posting) instructions from local.

Source: http://wiki.sdn.sap.com/wiki/display/SSC/Best+Practise+Finance+Processes+in+Shared+Services