SAP BEST PRACTICE FINANCE PROCESS IN SHARED SERVICES Procure to Purchase(P2P), Customer to Cash (C2C), General Accounting(...
Best Practise Finance Processes in Shared Services     This part will describe the best practise finance processes in a sh...
Accounts Payable-Procure to Pay (P2P)Accounts Payable / Procure to Pay (P2P) Process OverviewThe Accounts Payable / Procur...
As mentioned above, incoming invoices can be delivered to SSC in a direct or indirect way.In most cases the address will r...
4. Double postings    SSC is running the duplicate analyzer. Two related documents are reviewed whether they represent two...
coming from ISP standard report run by SSC clerk and this proposal is then sent to the local units responsible for approva...
Vendor Master Data MaintenanceVendor Master Data Set-up/MaintenanceThe process Vendor Master Data Set-up/Maintenance inclu...
Accounts Receivable-Customer to Cash (C2C)Accounts Receivable/ Customer to Cash (C2C) Process OverviewAccounts receivable ...
Fig 9 - Corporate TreasuryThe electronic bank statements are now also available and viewable in the ISP system.For practic...
Although this process in handling stays completely in the responsibility of the local unit, there is still a small interac...
Fig 1 - C2C Challenges    Main goal of monitoring and collection is to get a firm grip on these challenges. This can be re...
The starting point is of course the invoice/receivable booked on to the customer.     In some cases countries have decided...
One other very important aspect of the A/R process collections in the SSC environment is the information sharing.Therefore...
Other areas like commercial/sales departments also often have valuable information on disputed (sometimes even before an i...
Reporting    Reporting    On a monthly basis the SSC A/R Clerk will create and send out a "CFO reporting package" to the r...
General Accounting (GA)The General Accounting processThe General Accounting (GA) process combines all processes that are r...
Upcoming SlideShare
Loading in …5



Published on

This document relates to SAP Best Practices of Finance Processes - P2P, C2C and GA in Shared Services. I have collected this information via SAP SCN and ©2012 SAP AG GERMANY – COPY RIGHTS OF SCN

Published in: Education
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. 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
  2. 2. 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 * Unique process steps * Transactional * Exceptional process steps * High Volumes * Statutory requirements * Repetitive * Customer facing steps * Low/Medium Risk * 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 Overview2. Vendor Master Data Maintenance3. Request to Receipt4. Invoice Processing5. Payment Process6. Monitoring7. Period Close Accounts Receivable / Customer to Cash (C2C)1. Process Overview2. Customer Master Maintenance3. Credit Control / Credit Management4. Manual postings5. Monitoring and Collection of Receivables6. Bank reconciliation7. Period end closing8. Reporting General Accounting (GA) 1. Process Overview (consolidated) ©2012 SAP AG GERMANY – COPY RIGHTS OF SCN
  3. 3. Accounts Payable-Procure to Pay (P2P)Accounts Payable / Procure to Pay (P2P) Process OverviewThe Accounts Payable / Procure to Pay (P2P) overall process covers the complete cycle from Vendor Master Maintenance through procurement and Vendor InvoiceProcessing, the resulting Payment Processing to external vendors and the Period Closing Activities. All processes are accompanied by comprehensive and maturemonitoring 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 ascanning and optical archiving infrastructure needs to be in place to support the workflow functionality. The optical archive storage system needs to fulfill legal and taxrequirements to enable the storage of original documents.Accounts payable /P2P Process interfaces at SAPs SSCIt 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 theadministrative effort of transferring paper invoices into electronic formats, more advanced companies have centralized the AP processing completely. In this case invoicesare 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 anefficient 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 andquantities on the invoice. The invoice is scanned to be available electronically in the system.Invoice ProcessingInvoice processingInvoice bookingThe 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 aclear 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
  4. 4. 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 units 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 regularlocal address and will be received by local units 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 scenarios 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 EnterpriseScan). 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 notificationin 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 postingprocess is therefore relatively easy, because the purchase order carries the necessary information for the posting. After the posting is saved, the FI posting on thevendor 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 workflowto 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 invoiceand 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 postingitself 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 clerkswill 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 rejectionletters 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/filingSince 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 countrys law requires a storage period for invoices, it will be agreed with the SSC that invoices will be send back to the local units office.MonitoringMonitoringIn 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 theconcerned local units:1. Vendors with a debit balanceExtract vendors which need to pay the company, instead of the company paying them. Thesevendors will be dunned (sending of reminder letter) to address the due payment to them.2. Items older than 4 weeksItems 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 andrequests that the outstanding item should be cleared or rejected.3. Items over specific amount/sensitive itemsHere 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 thelocal 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
  5. 5. 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
  6. 6. coming from ISP standard report run by SSC clerk and this proposal is then sent to the local units 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 accountsAt 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 theaccounts 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 needsthen 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 thebalance 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 themissing invoices.- Reconcile vendor accountsDepending on the Service Level Agreement with the local unit, the SSC clerk sends reconciliation statements to vendors. A possible agreement could be for example: Thetop 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 invoicebooking 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 backinto 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, checkedby the SSC clerk, the local units 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 reportsIn 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 isa year-end activity).Request to ReceiptRequest to ReceiptThe process Request to Receipt covers the procurement activities within local organizations. The responsibility for this process stays with the local units and the GlobalPurchasing 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. Afterthe bid selection, a shopping cart is created by the Purchaser. Once it has been approved by the managers cost center or the Managing Director, the shopping cart ostransformed 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 ActSarbanes-Oxley ActThe 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 inresponse to recent and prominent corporate failures, such as Enron, Worldcom, among others.Due to SAPs listing on the New York Stock Exchange (NYSE), the Act applies to SAP, and stipulates extensive requirements for corporations in the areas of publicdisclosures and internal governance procedures.As one of the core requirements linking companies internal governance structures with their external disclosure obligations, the Act requires a companys CEO and CFO toprovide a certification along with each of its filings of quarterly results stating that both officers have reviewed the companys 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 companys business processes. On thethreat 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 companys internalcontrols 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
  7. 7. Vendor Master Data MaintenanceVendor Master Data Set-up/MaintenanceThe process Vendor Master Data Set-up/Maintenance includes activities of requesting a new vendor or vendor changes, processing the committed data and the SOXcompliant approval of all changes. The final product - updated or new vendor master record - is used for procurement and Accounts Payable purposes. Technically thedescribed process is implemented as an SAP Business Workflow started by a WEB Dynpro to enter the request data as an Employee Self Service Scenario. Attacheddocumentation (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 ( information) are therefore also subject of the full approval process. ©2012 SAP AG GERMANY – COPY RIGHTS OF SCN
  8. 8. Accounts Receivable-Customer to Cash (C2C)Accounts Receivable/ Customer to Cash (C2C) Process OverviewAccounts receivable (AR)/Customer-to-Cash (C2C) is the second most often-deployed process by SSCs. Companies generally keep AR inside the companybecause a close relationship to its customers is often considered a companys most important asset.The process covers the area from Customer Master creation, through Collection, Dispute and Dunning Management to eventually booking of incoming payments ofcustomers. Furthermore it covers the area of daily bank reconciliation (incoming and outgoing mutations on banks/bank statements) plus invoice creation (invoices otherthen standard billing).For the activities monitoring and period close activities are also performed.Assumption for an effective C2C processThe 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 processesin 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 billingdepartments (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. Thecollection 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 ishandling 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 areas (eg their own contacts with customers, or from internal departments, or fromexternal 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 reconciliationBank reconciliationThe 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 SAPs headquarter creates from these electronic bank statements, on daily basis, batch-input-sessions for posting the items on the banktransitory accounts and clearing/posting open items on sub ledger accounts. ©2012 SAP AG GERMANY – COPY RIGHTS OF SCN
  9. 9. Fig 9 - Corporate TreasuryThe 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 arebeing processed, and for every bank mutation on the processed bankstatement the system will automatically go look for "matching data" in the mutation line item. Mostcommonly 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 automaticposting 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 notsee, 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 hasthe 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 adviseBasically 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, saveit, 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 hasthen 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 occuranceof 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 bedone 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 onesneed 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/Ltransitory 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/alignmentbetween global treasuries, A/R responsible and customers is necessary in order to reach the goal of high quality data.Credit ControlCredit Control / Credit ManagementThis process, containing activities such as credit risk analysis, solvency analysis and customer credit status evaluations and setting credit limits is handled fully at theserviced 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 isdone 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 MaintenanceCustomer Master Data Set-up/MaintenanceCustomer master data records are containing all specific data related to a specific customer such as name, address, telephone, bank details, sales related data, standardpayment 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 masterdata. ©2012 SAP AG GERMANY – COPY RIGHTS OF SCN
  10. 10. 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 units responsible person. Changes in the master especially for changes in the bank details (can be necessary for refunding of creditamounts). 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 ( mail) for further processing.Manual postingsManual postingsManual 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 plansNote: 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.RepaymentsA 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 customerbalance. 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 isthat 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, suchas 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 plusthe customer request will then be signed by the SSC C2C manager and after 1 st signature forwarded to the local units responsible. After his/her approval, the form is sendback 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 P2Pdepartment 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 theamount will automatically be paid out (for payment run details, please refer to the P2P process)Instalment plansA 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 thedue 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 letterconcerning 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 theplan 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/instalmentswith 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 openitem. 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 isthen 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. Atthe 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, hasbeen received on time.Monitoring and Collection of ReceivablesMonitoring and collections of ReceivablesThe 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 createdand 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 daysnett", 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 blockthe "flow to payment" : ©2012 SAP AG GERMANY – COPY RIGHTS OF SCN
  11. 11. 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 Managements 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
  12. 12. 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
  13. 13. 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.DunningParallel 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 theA/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 invoicewhich is due 7 days receives a 1st dunning letter, every invoice which is 14 days due receives a 2 nd dunning letter, and invoices due more then 35 days receive a final/lastdunning 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 itemsexisting on the run-date. The proposal list is then checked and altered/approved or directly approved by the local units responsible. After the approval the dunning run isfinalized 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 directlyfrom 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: openitems which have dunning level 1 and 2 (so items which received a 1 st or 2nd dunning letter) are collection responsibility of the A/R SSC clerks; items with 3rd level arehanded over in collection responsibility to the local A/R unit.Dispute ManagementDispute ManagementThe 3rd sub-process in monitoring & collections is called Dispute Management. This is the area where all disputed invoices are monitored, forewarded to the responsiblepersons, 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 issueThe 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 contactperson, missing purchase order nr etc. In most cases a new invoice has to be created and the old one will be credited.2. Commercial issueThe received goods/services are disputed. Therefore the invoices for these deliveries are blocked for payment until the issue is solved. The involvement of commercialcolleagues 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 aboutopen 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 theinvoice). ©2012 SAP AG GERMANY – COPY RIGHTS OF SCN
  14. 14. 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 fromISP/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 areas - invoice issue - and - commercial issue, can beselected 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 (disputeindicator 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 standardcollection contact such as dunning letters and/or calls/emails etc. Therefore it is important that all responsible departments involved in solving disputes, such as billingdepartments 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 existingdisputes. Solving disputes is one of the key factors for improving the company’s customer satisfaction.Period end closingPeriod End ClosingFor 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 localside:- 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 orsimilar 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
  15. 15. 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
  16. 16. General Accounting (GA)The General Accounting processThe 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 arerelated to other Finance & Accounting activities. In the picture below the general accounting sub-processes and activities are described as they are handled by SAPs SSC(or in combo with the serviced local organization). For all period end closing activities the main control goes to SSC and end responsibilities are remaining at the localorganisation. The SSC provides on bases of local instructions transactional closing activities or automatic transactional closing activities without instructions (which is thenpart 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 andreconciliation 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 theFinancial 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 servicedlocal unit, and in other occurrences with (posting) instructions from local.Source: ©2012 SAP AG GERMANY – COPY RIGHTS OF SCN