Common EP&MEA Accounts Receivable Process V6.0 July PDF

Common EP & MEA Accounts
Receivable Process
Revision Number 6.0

February 2019
Common EP & MEA Accounts Receivable Process Document V5.3
Document Control Section / History

Author: Caroline Leconte, Process SME in AR&Invoicing squad– Europe and MEA
Ownership & Approvers:
Role Name Title

Document Caroline Leconte Process SME in AR&Invoicing squad
Owner
Document Steve Briggs Leader, Q2C A/R Operations & Planning - Europe
Approver
Document Thorsten Dahlke AR Market Leader MEA

Approver
Document Joan A Nelson Director Global STS A/R Transformation

Reviewers Jana Marcinekova Manager B/S AR & PDA Accounting Europe and
MEA
Steven A Jones Associate General Counsel, Trust & Compliance
Officer Europe & MEA
Tibor Goncz Regional Credit Officer - Europe, MEA
Deirdre Boyd Treasurer – Europe and MEA Treasury
Karl Minahan VP, Global Treasury Operations
Lucia Jablonovoska EMEA Accounts Receivables Operations Leader
IBM Confidential Page 2 of 152

Revision History:
Revision # Revision date Summary of Changes

V6.0 May 2019 • 5.2.2 : added a note on the responsibility of the collector to check the
customer entitlement to receive copy of invoices and letters
• 5.8.3. Write off : COD /blacklist not needed for credits or payment
write offs
• 5.8.3. Write off reason codes : link added to box for overview for all
countries
• 5.8.3. Removal of the notifications to business for the w/o of credit
notes.
• Adding Engage AR next to CDMS in the whole process
• 5.3 : Update of the dispute metrics to the global dispute
measurements
• 5.5.Removal of the 4Q 2018 accounting guidance on write off for
suspense cases
V6.0 February 2019 • Introduction and Purpose chapter: added Austria and Switzerland to
the countries to move to iERP
• Additional instructions for write off of external factored debt
• Update on the COD/blacklist flagging of bad debt or suspense cases
• Negative confirmation instructions under Cash application
• Replacement of SOL and IOL by Invoices
• Update on the small value write off criteria
V5.3 July 2018 Ownership & Approvers: names and roles updated
Introduction and Purpose: IGF AR collection
Update of names to Agile terminology.
Replaced STS by Q2C
AP11 replaced by AP AR
Removal of all the standalone IGF processes as per transfer of responsibility
of AR activities to IGF Budapest team
Added Kuweit, Azerbeidjan and Mauritius to iERP countries
4 : AR Key roles. Removed BC and replaced by Process SME and Testing
and compliance
5.1.Added countries Greece and Cyprus, Germany in scope of LowTouch
Update on the LowTouch activities
5.2.2. Removed reference to Business Analytics and added reference to
Smart AR Watchme widget
5.2.2.Collection Management and 5.6.1.Setting Targets and Objectives :
removed CCR as no longer a collection target
5.5.Pre-Legal Administration : New write off criteria for suspense case added
5.7. AR Testing and Compliance (instead of Business Controls)
5.7.6. : sunset of the CCM alerts
5.8.3 : COD flagging exclusion , approvals and how to document, updated
7. Replaced Reporting and Data Management by SMART team

V5.2 June 2017 - Contacts in reviewers list updated.

- AR Low Touch Collector responsibilities added to roles and responsibilities section
- Included section 5.1 Low Touch Collection Activities
- 5.2.2 Collection Management
- Frequency to review excluded customers from EMEA Collection plan updated
from quarterly to yearly.
- Automatic write off robot clip level updated from 35$ to 100$ (only applicable
to trade)
- Added reference that DSW Auto renewal invoices are excluded from common
collection plan
- Included recommendation to use WatchMe widget for the collection activity
control and removed reference to BA due to discontinuance.
- Frequency of control modified from monthly to twice a month,
-5.2.11 Forecasting: New dispute forecasting (new section also included under Dispute
Management)
-5.2.12 Late Payment Fees. Updates on documentation to be provided for cancellation
requests (IGF). Removed reviewer role for France. GL accounts for LPC write offs
updated.
- 5.2.14 Factoring
- Included new countries where Internal Factoring contracts are available,
reporting responsibility of the AR Focal Point and link to DLP in QMX.
- Internal factor updated from I.I.H. (IBM International Holdings in Ireland) to IBM
United Kingdom Financial Services Ltd)
- 5.3 Dispute Management:
- Included reference to May 2016 agreement of GBS, IS and TSS DRO
delegation to STS
- Claim process clarification
- Clarification on concession process and disputes.
- 5.3.7 Notification Letters
- Added link to DLP
- Included new section 5.2.9 IGF International Support Structure (IISS)
- 5.5 Pre-Legal Administration: included a reference to CoD not being applicable to
Softlayer
- 5.7.5 Sarbanes Oxley
- Removed SOX control point KCO 501, 503, 508, 509, 511 and 512
- IGF testing reported under IBM LLC in WWBCIT
-5.7.6 CCM Process (Continuous Controls Monitoring): included new rule 12
implemented in Mar17
-5.8.1 Adjustments: Included possibility to perform Due Date Change based on PO if
previously approved by contract management.
-5.8.2 Refunds: updates on AAT usage.
-5.8.3 Write Offs
- New COD flagging guidelines for trade Write Offs.
- Included credit note write off process.
- Updates on WO reason codes, WO automatic robot, COD flag requirements
& AAT usage.
- Revision and replacement of links to Finance and Accounting instructions
- June 2016 Updates June 2016:
-5.1.11 Late Payment Fees: new countries in LPCAT (CEE and South Africa)
-5.1.2 Collection Management: Automatic WO robot on remaining balance $100 not
applicable for IGF
- 5.3.3.3 Credit Card: including new Global Credit Card clip levels and link to DLP
-5.4 Pre-legal Administration: COD & Black List process principles: recommended
quarterly review
-5.7.3 Write-offs: clarifications on Trade Concession Process and on removed sentence
on Accounting approval.

V5 March 2016 - Updated Reviewer list

- 5.1.1 Late Payment Fees
Updated process for IGF LPF Management due to the implementation of the Late
Payment Charge Approval Tool (LPCAT)
Included references to new DLP documents to aid the different roles in LPCAT
- 5.1.2 Collection Management
Updated Small Delinquent Debt (SDD) chapter considering the implementation of BA
Recommendations
- 5.1.13 Factoring
Updated External factoring process
- 5.2.6 Notification Letter Process
Exclusion of B2B customers
AR Collection responsibility when opening disputes is included
- 5.2 Dispute management . OPC link
- 5.3.3.1 Cheque Cash Accounting Instructions updates
- 5.3.3.3 Credit Card
Included new credit card models
General process updates including flowcharts, description of process & changes in role
responsibilities
Linkages to 9 new DLPs:
AR_Global_Credit Card Virtual Terminal Refund Exception Process
AR_Global_Credit Card Chargeback
AR_Global_Credit Card Exception
AR_Global_Credit Card Incident Reporting
AR_Global_Credit Card Pending Payment URL
AR_HIGH LEVEL_Credit Card Pending Payment URL
Credit Card After Invoice DLP
Credit Card Refund DLP
Credit Card Rejected FCO & RCO DLP
- 5.3.4: Cash treatment and Accounting Instructions
- 5.3.5 Direct Debits
General updates and linkage to new DD Management Non SEPA countries DLP
- 5.3.6 Direct Debits - Single Euro Payments Area (SEPA)
Updated process specific to the acceptance of DRE/RRE files into CARS
- 5.3.11 Cash Administration
Updated section D. Proforma Invoices and Prepayments to include a link to
Prepayments DLP to clarify flagging criteria/ conditions to be met.
- 5.4 Pre-Legal Administration
Clarification or pre-legal output options
Update to COD & Black List process and steps/responsibilities are defined further due to
the implementation of a new COD flag available in CDMS
Inclusion of a new updated process due to the implementation of AR Suspense
Management Tool (STT)
Updated countries list: common flagging for suspense situations
Added links to new DLPs:
Pre-Legal Activities DLP
Cash on Delivery (COD) and Black List DLP
Use of A/R Suspense Tracking Tool (STT) DLP
- 5.5.1 Setting targets and Objectives
Updated Current Clearing Rate information to include a note that this target is in the
process of being updated to a pure 0-30 target
- 5.6.3 Self assessment & Compliance Test
The process is updated to be compliance tested every quarter and not monthly.
- 5.6.5 Sarbanes Oxley
Key Controls testing update specifying specific storage requirements
- 5.6.6 CCM Process
Updated AR Rules to no longer include Rules 6, 10 and 11.
- 5.7.3 Write-offs
Responsibilities / Ownership section is updated to exclude referencing the Treasury
function
Write Offs Update on Write-off concessions and bad debt COD/Black List flagging
- 7 Reporting and Data Management
Replaced references to ARIW with the WW AR Reporting Tool or Global Tables

4.9 January 2015 - Changed Approver and Reviewers list in line with new organizational structure
- Changed document title to include a specific reference to MEA
- Updated 4. A/R Roles and Responsibilities
- Excluded references to Germany in this document considering that a unique process
document entitled ‘Germany A/R Process’ covers the Blue Harmony environment
-5.1.2 Collection Management
Updated information regarding performance monitoring/ KCO501 monthly review
requirement by A/R Manager (or delegate)
Stressed a recommendation to contact customers prior to invoice due date when invoice
due date is greater than invoice date
-5.1.3 CDMS usage for Collection activities
Overhaul of forecast suggestions aligned to action codes (due to new additions/deletions
of action codes in CDMS)
-5.1.6 Deferred Payment Agreement
Clarified the description to indicate that DPA proposals should not form part of normal
collection activities
Included a recommended limit for DPA duration
Clarified that approvals should be resought for any second rescheduling
-5.1.10 Forecasting
Clarified that forecasts should not be deleted but instead updated
-5.1.11 Late Payment Fees
Updated instructions for LPF write-offs through G/L adjustments
Included a note on the status of a new tool (LPCAT) that will assist with LPF proposal
validation
- 5.1.8 Consolidated Statement Facility
Updated action code guidance for CSF accounts
-5.2 Dispute Management
Updated minimum details required for registering a dispute
Note on Ownership from GTS business teams to STS Services (Europe IOT only)
Clarified the way in which dispute resolution should be communicated to clients and BPs
Updated the rules concerning the negative confirmation approach
Included new dispute measurements
-5.3 Cash Administration
Updated guidance for withholding tax
-5.3.6 Direct Debits –Single Euro Payments Area
Inclusion of new guidance related to the implementation of the Global Direct Debit
Gateway (GDDG) impacting specific countries in the eurozone
- 5.4 Pre-Legal Administration
Included specific information as to how suspense flagging in CARS should be handled
for when only part of the debt should be flagged
-5.6 AR Business Controls
Updated roles
Updated Control Points table
Added a note regarding KCO503 (Suspense Monitoring Process Guidelines) indicating
that this control is not yet ready to be implemented
-5.7.2 Refunds
Removed Denied Parties List (DPL) check as it is no longer mandatory for inclusion in
the refund package
7. Reporting and Data Management
Updated F) Planning and Tracking of AR Collection contribution to DSO
4.8 September 2013 - Renamed all CF to STS (CF)

- Changed Reviewer List according to new organization STS
5.2. Dispute Process: Note on Ownership from GBS Business teams to STS Services
(Europe IOT only)
- split chapter “Plans & Controls” into 5.5. “AR Planning” and 5.6. “AR Business Controls”,
enhanced chapter on BC with information from old chapter 8 on Key Control Testing
- added new guidance on Late Payment Fees to be written off via General Ledgers
throughout the document
- dedicated chapter for 5.1.3. CDMS Usage for Collection activity
- several notes on BH implementation
- added SOX KCO 503
- 5.4. added COD / Blacklist information
- added new chapter 5.7. File Maintenance
- 5.7.2. Refunds: added information regarding Credit Notes that cannot be refunded

4.7 July 2012 0. Reviewer list updated

2.Account Receivable Process Definition and Objectives:
- Sub-process table updated
5.1.2 Collection Management
- Reference to Europe Collection Plan updated (CEE inclusion)
- Inclusion of SDD process description
- Update of CDMS Usage for Collection Activities description
5.1.4 Delinquent Account Management
-Inclusion of Cancel for non Pay guidance
5.1.10.2 LPF Management process for IGF
Clarification of Exclusion process management as per IGF guidance
5.1.11 Arrears Letters:
Clarification about shorter Arrear Letter program/timing
5.1.12 Factoring:
-Commercial Financing process updated
5.2 Dispute Management
-Inclusion of the global dispute definition
-Inclusion of clarification regarding internal identification of a dispute
-Modification of the structure of the Dispute Management Process: subchapters now for
the different Roles (& their Responsibilities)
-Improved description of the responsibilities per Role
-Inclusion of a basic flowchart of the Dispute Management
-Inclusion of mandatory details for a dispute
-Inclusion of COF specific dispute process
-Additional chapter on the difference between Solved and Closed
-Description of Dispute Refusal & Rejection
-Update of the Notification Letter Process
-Clarification of the Negative Confirmation Process
-Update of the Automatic Dispute Escalation Process
-Removal of Q1/Q2 and X2 (disputes for payment terms) from Process document and
included in the Appendix
5.3.1 Cash Application
- Clarification about withholding tax deduction
5.3.2 Unallocated Cash Management
- Updated guidance about minimum requirements for a UAC write Off
5.3.4 Refunds:
-Clarification on negative confirmation usage
5.3.5 Write-Offs
-Clarification added about documentation back-up
5.4 Pre-Legal Administration
- Clarification on wording on description of new AP11 version conditions to flag Suspense
cases
5.5 Planning and Controls: Clarification added
6.2 Invoicing: Reference added about Advance Invoicing and Compliance Invoicing.
7. Reporting and Data Management: Clarification added
7.1 Corporate and Europe Reporting: Clarification added
7.3 Operational & Management Reports: Clarification added
8 A/R Business Controls Guidelines – Key Control Testing: Clarification added.
- Key Control Objectives updated

4.6 November 2011 0. General update: inclusion of Global QMX links to any related chapter
1.Introduction and Purpose: Global CF Process Library (common process repository
data base)reference has been added
2.Account Receivable Process Definition and Objectives:
- Current AR process ownership delegation has been added
- CF Cash Allocation sub process have been further clarified
- "Non customer AR" cases have been added to the AR out of Common Process
guidance
3.IBM World Wide Payment Terms (WWPT’s): chapter structure has been updated (no
changes in content)
4.Accounts Receivable Roles and Responsibilities:
- Further clarification about some AR responsibilities (adjustments) and team Job roles.
- Reference to the combined role for Prelegal Analyst & Collector in some Europe regions.
5.1.2 Collection Management
- Europe Collection Plan has been referenced
- New guidance for Invoices less 1000$
5.1.8 IPP: Description added for CEE scenario.
5.1.9 Forecasting: Forecast definitions updated to the Global ones
5.1.10.2 LPF Management process for IGF: Updated Exclusion process management
as per IGF guidance
5.1.10.3 LPF Management process for Trade:
- Further clarifications about the process management.
- Alignment of Exclusions Management section to the stated in FIN180
5.1.11 Arrears Letters: Further clarification for the AL timing
5.2 Dispute Management:
- Process description has been updated in order to clarify some unclear wordings
- Clarification of Internal/External claims management in dispute process has been added
- Referenced Notification Letter process used by DROs to resolve disputes and AR
involvement identifying customers to be excluded of this solution
- Referenced Global PO process and AR involvement on waiver cases
- Updated disputes measurements
5.1.12 Factoring: Control/Reconciliation description has been removed (not under AR
process)
5.3.1 Cash Application
- Clarification about timing required for cash allocation
- Referenced Withholding tax deduction scenario
- UAC clarification and allocation management has been further clarified
5.3.4 Refunds:
-Clarification on cases where manual flow with Treasury Operation systems is required
(to be documented in AAT package previous to final Cash Admin approval)
- Removed Reconciliation description (out of AR process scope)
5.3.5 Write-Offs
- Write off check list has been further clarified
- Write off robot has been updated (IGF is now included)
- Removed Reconciliation description (out of AR process scope)
5.4 Pre-Legal Administration
- Further clarification of COD/Blacklist activation for cases under Perlegal
- Clarification on wording regarding contract cancellation
- Updated description of new AP11 version conditions to flag Suspense cases
5.5.2.5 Sarbanes Oxley: CCM (Continuous Controls Monitoring) process description
has been added
6 Application Architecture: AR Europe Action plan for systems black-out contingency
scenario has been added
7 Reporting and Data Management: Clarification added
4.5 October 2010 • Updated FIN180
• Updated Collection Management
• Updated Distressed Account Management
• Updated Delinquent Account Management
• Updated Promissory Note section to Deferred Payment Agreement
• Updated Statements / Customer Account Reconciliations
• Updated Late Payment Fees
• Updated Arrear Letters
• Factoring
• Dispute Management
• Cash Administration
• Pre-Legal Administration
• Planning and Controls
• Reporting and Data Management

4.4 October 2008 • Updated Refund Process

• Updated Write-Off Process
• Minor further updates as outlined via Track Changes functionality
4.3 September 2008 • Updated Roles section
• Updated LPF Process
• Updated Commercial Financing Process
• Updated Cash Administration Process
• Updated Dispute Management Process
• Updates Write-Off Process
• Updated Controls section
• Minor further updates as outlined via Track Changes functionality
4.2 October 2007 • Updated Unallocated Cash Process
• Updated Document Control section
• Updated WWPT according FIN180
• Nomenclature: EP & MEA replaced by Europe
• Inserted already approved changes in Dispute Management Process
4.1 June 2005 • Updated disputes closing definition
• Updated write-offs responsibilities section
4.0 January 2005 • Clarification of A/R Process ownership & boundaries, slight update to WWPT’s
text
• Distinction and documentation of Distressed and Delinquent management
• Revised disputes definitions and new WW codes
• Updates of the Pre-Legal, Refunds, Forecasting and CSF sections
• Addition of reference to Sarbanes Oxley and CDMS Action Codes
3.0 January 2004
2.0 January 2002
1.0 January 2000
Distribution: Through Finance & Q2C to any Europe & MEA personnel involved in the
Accounts Receivable Process.
Validity of this document:

This document is valid for 12 months from approval date. In the event that the current document
expires before the renewal document is published, the current Common EP & MEA A/R Process
document will remain in effect with no changes.

Contents
1. Introduction and Purpose ...................................................................................................... 12

2. Account Receivable Process Definition and Objectives ....................................................... 13
2.1. Definition ................................................................................................................................ 13
2.2. Accounts Receivable Environment ....................................................................................... 15
2.3. Objectives .............................................................................................................................. 16
2.4. Deviation approval request.................................................................................................... 16
3. IBM World Wide Payment Terms (WW PT’s) ....................................................................... 17
4. Accounts Receivable Roles and Responsibilities ................................................................. 17
5. Sub-Process Activity Descriptions ........................................................................................ 20
5.1. Low Touch Collection Activities............................................................................................. 20
5.2. Collection Activities................................................................................................................ 22
5.2.1. Maintain/update Customer Information ......................................................................... 22
5.2.2. Collection Management ................................................................................................. 23
5.2.3. CDMS Usage for Collection Activities............................................................................ 31
5.2.4. Distressed Account Management .................................................................................. 34
5.2.5. Delinquent Account Management.................................................................................. 35
5.2.6. Deferred Payment Agreement (DPA) ............................................................................ 37
5.2.7. Statements / Customer Account Reconciliations .......................................................... 38
5.2.8. Consolidated Statement Facility .................................................................................... 39
5.2.9. IGF International Support Structure (IISS) ..................... Error! Bookmark not defined.
5.2.10. IPP .............................................................................................................................. 41
5.2.11. Forecasting ................................................................................................................. 42
5.2.12. Late Payment Fees .................................................................................................... 47
5.2.13. Arrears Letters ............................................................................................................ 50
5.2.14. Factoring ..................................................................................................................... 54
5.3. Dispute Management ............................................................................................................ 58
5.3.1. Definition......................................................................................................................... 58
5.3.2. System Support .............................................................................................................. 61
5.3.3. Roles & Responsibilities................................................................................................. 61
5.3.4. Dispute resolution: definitions of Solved and Closed Dispute Status ........................... 66
5.3.5. Automatic Dispute Escalation Process .......................................................................... 68
5.3.6. Forecasting of invoices in dispute .................................................................................. 69
5.3.7. Notification Letter Process ............................................................................................. 69
5.3.8. Specific Dispute situations ............................................................................................. 70

5.3.9. Dispute Measurements ................................................... Error! Bookmark not defined.

5.4. Cash Administration .............................................................................................................. 72
5.4.1. Cash Application ............................................................................................................ 73
5.4.2. Unallocated Cash Management .................................................................................... 91
5.4.3. Alternative Payment Methods ........................................................................................ 93
5.4.4. Cash Control ................................................................................................................ 101
5.4.5. Direct Debits ................................................................................................................. 103
5.4.6. Direct Debits - Single Euro Payments Area (SEPA) ................................................... 106
5.4.7. AR Accounting.............................................................................................................. 108
5.5. Pre-Legal Administration ..................................................................................................... 109
5.6. AR Planning ......................................................................................................................... 119
5.6.1. Setting Targets and Objectives .................................................................................... 119
5.6.2. AR Data Coordination .................................................................................................. 120
5.6.3. Process linkage and Management .............................................................................. 121
5.7. AR Testing and compliance ................................................................................................ 122
5.7.1. Separation of Duties..................................................................................................... 122
5.7.2. Process Controls and Documentation ......................................................................... 123
5.7.3. Self-Assessment and Compliance Test ....................................................................... 123
5.7.4. Audit Requirements...................................................................................................... 123
5.7.5. Sarbanes Oxley ............................................................................................................ 124
5.7.6. CCM Process (Continuous Controls Monitoring) ........................................................ 126
5.8. File Maintenance ................................................................................................................. 127
5.8.1. Adjustments .................................................................................................................. 127
5.8.2. Refunds ........................................................................................................................ 129
5.8.3. Write-offs ...................................................................................................................... 134
6. Application Architecture ....................................................................................................... 141
6.1. CARS RO Architecture ........................................................................................................ 141
6.2. Invoicing ............................................................................................................................... 142
7. Reporting and Data Management ....................................................................................... 144
7.1. Corporate and Europe Reporting ........................................................................................ 145
7.2. Reconciliation Reports and Requirements.......................................................................... 148
7.3. Operational & Management Reports .................................................................................. 151
Appendices ................................................................................................................................. 152

1. Introduction and Purpose

This document intends to describe the end to end Accounts Receivable Process including cross
functional responsibilities and linkages to upstream and downstream processes, for the Europe,
CEE and MEA regions.
It excludes A/R processes for iERP countries (Germany, Kuweit, Mauritius, Azerbeidjan)
as instead, a unique document entitled ‘Germany A/R Process’ covers the iERP
environment. As from June Austria and Switzerland will also be moving to iERP.
Note: This document is applicable for the Services Integration Hub (SIH) entities.
IGF is no longer responsibility of Q2C AR and all the standalone IGF processes are therefore
removed from this version of the Common process.
This document is also designed to define the “Common EP & MEA Accounts Receivable
Process” for harmonization throughout the geographies, and to additionally support the
migration of all Accounts Receivable applications to common applications such as CARS Run-
Once and CDMS or Engage AR . Engage AR is being deployed in all EMEA countries during
2019
It is to be used as a Template by all Europe and MEA countries and across all revenue streams
and business units, including IBM controlled Subsidiaries, for standardizing the process of
Accounts Receivable.
The Process is designed to support FIN180, IBM’s World Wide Payment Terms which are
defined in chapter 3. Therefore all the procedures and the CARS functionality built to support
them, are based upon Invoices being Due upon Receipt, so that normally – barren approved
country deviation being in place - invoice date equals invoice due date.
The document should enable a strategy of ‘a common AR process supported by Run-Once

applications’ to be implemented through elimination of country variances and standardization of
roles and responsibilities as well as systems architecture. This will also support deployment of
corporate instructions and best practices.
Standard reports and measurements are defined which will provide the majority of data required
in countries to support Corporate, Europe, IOT/ IMT and Country requirements, as well as
defined audit and business control needs.
Whenever approvals are required (for transactions or process steps), these must be subjected
to country Powers Reserved instructions.
Finally the process should support identified e-Business enhancements for now and for the
future.
Countries are asked to continuously review and assess their current process against the
Template. Each deviation has to go through a defined approval process (see chapter 2.4).
All countries should note that Accounts Receivable is defined as a Vital Process, because loss
or damage to the process would result in a significant loss of assets to IBM. Accordingly,
Accounts Receivable is to be included in appropriate Disaster Recovery Plans.

The document will be stored in the Global CF Process Library (QMX), as well as other repositories
(e.g. AR communities).
The Global CF Process Library is the common repository for all Q2C process documents in a
worldwide level. All Europe & MEA-level AR process documents have been stored in this QMX
library including further descriptions of the different AR sub-processes (under the Global Mapping
format) plus any other process guidance covering very specific scenarios and/or projects where
the AR intervention is not following the standard process stated in this document.
Please, find in the Appendix document the most updated list of AR process documents published
in the Global CF Library (appendix F).
2. Account Receivable Process Definition and Objectives
2.1. Definition
The Common EP & MEA AR Process starts with the creation of an invoice, and ends with the
settlement of the invoice, either by payment, credit or authorized adjustment.
The process includes:
• Planning & Controls

• Debt Collection
• Follow-up activity on overdue accounts
• Delinquent / Distressed accounts management
• Initiation of Pre-Legal and Legal proceedings
• Receipt of monies due to IBM
• Allocation of Cash to Customer accounts
• Write-offs, Refunds and other adjustments
• Ledger reporting and reconciliation support.
The Accounts Receivable Process is owned Worldwide by CHQ Treasury, with execution
delegated to Quote to Cash (Q2C) and ownership in each of the Geographies delegated to
Finance.

Ownership:
Accounts Receivable Process

(Owner: Finance / Treasury)
Planning & Collection Dispute Cash Reporting

Business Controls Mgmt Mgmt Administration & Data
Mgmt
Finance Finance
(linkage (linkage
AR Q2C & AR Q2C &
Finance AR with Finance Finance AR with
AR Q2C CoF Finance
(Treasury) Q2C Accountin (Treasury) (Treasury) Q2C Accounti
Involvement (Treasury)
g ng
Process) Process)
The various Accounts Receivable sub-processes are split in terms of ownership and/or execution.
Only Disputes Management is directly owned by one function, while the other sub processes have
interdependencies and Powers Reserved provisions.
IT Ownership for AR Systems is within Finance IT (CARS, CDMS, ARIW).
Sub-processes details:
Planning & Collection Dispute Mgmt

Business Controls Mgmt
(shared ownership) (shared ownership) (delegated ownership)
Finance
Finance (linkage with AR Q2C & CoF
AR Q2C Finance (Treasury) AR Q2C & CoF
(Treasury) Accounting Involvement
Process)
- Setting Targets - Target Reception - Reconciliation - Late Payment Fees - All collection sub- Note: Dispute Resolution
and Objectives and Plan require Treasury approval processes are Owners (anywhere in the IBM
- Reporting Construction of exceptions / exclusions delegated to AR organization) are responsible for
- WWPMT - Plan Cascade and interest to be applied Q2C with the resolving the disputes assigned
deviations and - Consolidation to - External Factoring exception of IGF AR to them by AR Q2C-
exceptions Forecast requires CHQ Treasury and IGF CoF, with For IGF CUF and CoF Initiation
- Incentives (e.g. - Tracking approval, internal factoring comments on on Disputes, this is with IGF.
EPI) Performance requires country treasury Treasury roles &
- Results approval powers reserved in
- Process linkage the left column
and Management
- Controls
- Separation of
duties
- Process Controls
and Documentation
- Self-Assessment,
Compliance Test
and Audit Support
- Audit
Requirements
Cash Reporting & Data Mgmt

Administration (shared ownership)
(shared ownership)
Finance (linkage with

Finance (Treasury) Q2C AR Q2C AR & Finance (Treasury)
Accounting Process)

- Cash Allocation - AR Accounting - Corporate and EP & MEA reporting

- Alternative Payment Methods
- Unallocated Cash Mgmt requirements
(decision)
- Alternative Payment Methods - Process Control and reconciliation
- Cash Control
(execution) reporting
- Partner Choice Prepayment
- Refunds (execution) - Operational & Management reporting
Program
- Write-offs (execution) requirements
- Adjustment
CFO:
- Direct Debits
- Write-offs (decision)
- Multi-Company
- Refunds (decision)
Cash Entry Control (KCFR 104)
The AR Process does not include:
1. Credit Risk Management, which is the subject of a separate process owned by Global Risk
Management. However, the interlock between the AR Process and the Credit Risk
Management Process is key, as data derived from the AR Process, such as Payment
Trends, Distressed Accounts, Customer’s Total Outstanding AR, is used to update
Customer Credit Ratings, and influence Credit Risk decisions. This document therefore
contains several cross-references to Credit Risk Management, and any AR Roles involved
in these activities must fulfill their responsibilities to communicate and update Global Risk
Management wherever changed Customer situations could impact Customer
creditworthiness.
2. Suspense Management. The operational country setup can currently include Q2C support
for bankruptcies and litigations, for Trade. However, the IBM direction is to autonomously
manage this set of specific Legal-related activities outside the scope of Accounts Receivable
process & within a dedicated organization. The Accounts Receivable process scope ends
once all approvals have been obtained by Q2C AR to move the accounts to Suspense, as
per AP AR & process steps detailed below in this document.
3. Accounts Receivable Accounting, which is directly owned by Accounting.
“Non customer” AR. The Common EP & MEA AR Process is designed to support
collection activities from IBM's customers for Trade wherever routed to CARS. In case any other
AR gets routed through CARS to FDW, Q2C AR would take care of allocating any payment
received to the specified invoices once the cash is received, but without pursuing a pro-active
debt collection process. Cash Administration will also handle adjustments in CARS to correct
inaccuracy or imbalance situation on the account including the preparation of AAT packages.
2.2. Accounts Receivable Environment

The common process defined in this document is to support the Accounts Receivable
environment summarized in the diagram below. The Accounts Receivable applications at the
centre of this process for IBM in Europe and MEA are CARS and CDMS/Engage
AR. For Germany, Kuweit, Azerbeidjanand Mauritus, SAP (iERP) is deployed. The concept of
run-once is to reduce cost and improve operational efficiency through the replacement of Country
run/supported applications with one central implementation. There are tradeoffs with this strategy,
and although there are many advantages to operate such a centralized environment, one
downside as far as an individual country is concerned, is that in some instances this approach
will be incompatible with the mode of operation previously deployed.

AR EN VIRON MEN T
Exchange Outside
Rate Treasury
Collection
System
s
r al
Direct Debits
Transmittals
fer
Payment
Exc Re
Refunds
han cy
ge gen
Rat A Dispute
es es
oi c Management
Inv tus
en Sta
Op t e
Billing Transmittals pu
Invoicing Dis
AR C/R Data
Customer
LPF dat a Records
Statements
ent r
Letters
ta y
g Da
DPA
untin Rep
Info
Acco or t s
Ledger Customer User
2.3. Objectives
• Provide Template for all Europe & MEA Countries to align current AR process.
• Standardize AR Process throughout Europe & MEA
• Support CARS Run-Once and CDMS and Engage AR deployments and standardization of
AR architecture
• Support full deployment of and compliance to World Wide Payment Terms
• Support AR e-Business requirements
• Enhance AR Process Business Controls
• Minimize duplicate AR IW data held in countries
2.4. Deviation approval request

Each country is asked to follow the Common EP & MEA AR process as defined in this document.
Any deviation has to go through the formal process using the “Invoicing & AR Country Deviation
Request Form”, in which a detailed description of the deviation has to be included e.g. Requester
details, process/sub-process involved, business justification, supporting documents. The process
has to be seen as an exception.
The following approval path must be completed:
1. First approver: Country A/R Manager/Squad Leader

2. Second approver: Process SME , AR&Invoicing squad – Europe, MEA with
concurrence of GEO leaders

3. IBM World Wide Payment Terms (WW PT’s)

The World Wide Payment Terms (WWPT), also referred to as the Global Standard Payment
Terms, for the sale of IBM products and services to commercial Customers, including Business
Partners, were published to all geographies by Global Contracts & Practices on August 26,
1996. These terms were approved by Corporate Finance and the Geographic CFOs. They are
being updated and republished now to ensure consistent execution and to eliminate any
opportunities for misinterpretation.
The latest version of the WWPT’s is always available in the Corporate Instruction FIN180 which
can be found in the IBM intranet:
https://w3-
03.ibm.com/ibm/documents/corpdocweb.nsf/ContentDocsByTitle/Corporate+Instruction+FIN+180
Complementing the WWPT’s, EMEA Treasury announces complementary guidance/approval

delegations (see in “Appendix D” the most updated version)
4. Accounts Receivable Roles and Responsibilities
Introduction
The Common EP & MEA AR process is broken down into a number of clearly defined elements.
These elements translate into tasks which mirror the new WW Q2C AR role definitions
described in Global CF Process Library which result in 9 specific roles and responsibilities.
In order to provide the agreed level of support to the AR process in Europe & MEA, and to
maintain auditable separation of duties, each of the five AR role types must be clearly separated
within a country or unit process and operational group, except otherwise stated in this
document.
This section describes responsibilities for each role, but does not intend to define organizational
structures (further individual job role descriptions should be in place by the AR teams based on
this core Roles and Responsibilities as well as taking into account the team’s local
specifications):
Roles and Responsibilities
The 9 AR Role types, and their responsibilities, are:
AR Low Touch Collector is responsible for:

• Tracking the Collection of accounts receivable for Low touch IBM mainline customers.
• Providing input to AR Collectors and/or the LT Collection Market Focal point on whether
direct interaction with the customer or AR system/database updates are required.
• Updating the AR database with Customer information
• Arrears Letter production and management

• Production of Customer Statements of Account and Customer Account reconciliations on

request
• Raising Adjustments (as per the Common Adjustment Matrix)
AR Collector, responsible for:

• Updating the AR database with Customer information
• Collection of accounts receivable for IBM mainline customers.
• Forecasting expected cash collect
• Arrears Letter production and management
• Production of Customer Statements of Account and Customer Account reconciliations
on request
• Collectors provide input to AR management on whether LPF should be aggressively
pursued for any delinquency based on management judgment considering specific
criteria and customer specific issues.
Delinquent Account identification and management
• Distressed Account identification and management
• Interfacing with Consolidated Statement Facility
AR Cash Administrator, (which excludes the Treasury Cash Control role) responsible for:
• Manual cash allocation, including underpayments, unallocated cash management, multi-
currency and multi-company allocation
• Alternative payment handling, including Credit Cards, Electronic Payments
• Direct Debit set-up and management
• Approval of Adjustments, including Refunds, Write-Offs
• Processing approved Late Payment Fee avoidances
• CARS reconciliations (with feeder applications)
AR Pre-Legal Analyst responsible for:

• Receiving and Analyzing Pre-Legal cases (delinquent and distressed cases transferred
from AR Collection to Pre-Legal)
• Case option recommendation
• Action plans and follow-up
• Support to Legal or Suspense Handling groups for litigation preparation
• Communicating relevant Bankruptcy/Insolvency situations (receivership and liquidation
in CARS)
• Updating the AR database with Bad Debt data (incl. Legal & Outside Agency status
before the move to Suspense occurred).
• Generation of appropriate accounting transactions for such situations.
Note: AR Pre-Legal Analyst and AR Collector roles are merged and executed by unique Q2C AR Collection
& Pre-Legal Analyst teams in countries where not enough resources are available to differentiate these two
roles (in most of CEE and MEA countries).
AR & Collection Planning Specialist responsible for:

• Planning
• Production of Forecasts
• DSO and Aged Debt target objective setting
• Performance management and review, including on the Collection Profile performance
• EPI management (planning and monitoring approved situations)
• Reports management (updating and refreshing of data in conjunction with the CARS User
Group)
Process SME for AR/invoicing and Kaizen squad

• Participating actively in all Vertical initiatives to further support the Globalization,
Standardization and Automation of the AR process
• Managing the AR Process on behalf of the country AR Manager who remains the owner
(Country Process Owner – CPO)
• Providing leadership, guidance and education to the AR community (Management and
Operations) on subjects related to AR process and testing and compliance controls
AR & Invoicing Testing and compliance responsible for:

• Ensuring the AR vertical has a positive controls and auditable position, including
performance of Key Control Testing
• Providing leadership, guidance and education to the AR community (Management and
Operations) on subjects related to AR process and testing and compliance controls
• Ensuring overall AR process integrity & controls compliance as defined per the Common
Europe AR Process
• Audit support
CSOL Agent responsible for:

• Providing a positive experience for clients submitting queries
• Contributing and responding to BP/customers actively handle non-phone requests, or in
case of complex requests, inform the BP/Customer that the request has been routed to
the responsible department and will be answered shortly
• Strive to solve queries at first contact
• Pick up the phone within the slightest delay
• Strive to effectiveness and accuracy when having a phone conversation
• Process e-tools entitlement request
• Comply with Blue Silence
• Comply with CSOL Global processes
• Receive, qualify and log in the CSOL Logging Tool BP/Customer queries received by
phone, e-mail, Web form, Web Request Tracking, chat, fax or letter.
• Handle simple requests and provide an immediate answer using personal knowledge,
existing application or available FAQs
• Handle complex or high workload request by routing it to identified SME for resolution
• Handle confidential requests (contract information and copies, client inventory and
warranty/maintenance status) running the authentication process whenever deemed
relevant. Answer BP/Customer request using agreed security rules and tools
• Helping to increase responsiveness by closely following up on non-FAR queries
• Driving clients to the web and thereby supporting Drive-to-Web targets

Group Structure and Deployment
All country/regional AR Operational squads should be constructed with AR Collectors, Cash

Administrators, Pre-Legal specialists, AR & Collection Planning specialists and Process SMEs &
Testing and compliance. Roles should be separated as identified in departmental Separation of
Duties matrices.
Deviations to the template must be approved following the Process Deviations approval process
as outlined in section 2.4 of this document.
ROLES versus System Access PROFILES
In order to maintain Separation of Duties and comply with Business Control requirements CARS
Run-Once will be set up based on the above described roles. The specific profiles are kept up to
date in line with the process design, system controls and organizational structure and available in the
“EP & MEA CARS CUG Team Room”.
5. Sub-Process Activity Descriptions

The Common EP & MEA AR Process is broken down into the following Sub-Processes/ activity
descriptions:
• Low Touch Collection
• Collection
• Cash Administration
• Pre-Legal Administration
• AR Planning
• AR Controls
• Reporting and Data Management
Each activity is described in the following sections, and further broken down to specific
procedures.
5.1. Low Touch Collection Activities

Low Collection team is dedicated to track and follow up the open IBM mainline debt of

previously defined customers with good payment behavior and/or with low billing in terms of value
affecting Madrid CoE Collection and therefore those where no direct contact is necessary or a
reduced collection effort is required for the selected accounts.
Low Touch collectors tasks:

1) On the last month of the Quarter: analysis is to be performed of customers potential based
on payment trend and year billing potential;
2) Selection of Low Touch potential and interlock with Collection Team to establish which
customers will be flagged under Low Touch Collection Units;
3) Once customers selection is made, build the query to daily run the Watch List for daily
tracking;
4) From the 1st Month of the Quarter daily tracking of the customers selected with the Watch
List file (Daily run);
5) Daily completion of Daily Tracking file with the Total Over 30 Potential (MEnd projection),
establishing the Potential and Cleared trends;
6) Follow up on customers with items over 45 days (from due date). This might defer by
market.
7) Regular interlock between Low Touch and Collection Teams
8) Send regular analysis to the Collection Teams, IMs and SLs
9) Provide administrative support to create AAT packages for Refund based on Collection
input. The approval paths are still maintained as per the Common Process (AR Squad
Lead is still the first approver and not Low Touch Collection squad lead.
Scope:
Low Touch Collection Team is only monitoring the activity of:
1) Customers with good payment behavior within 30 days from due date. Should a
customer start to demonstrate a consistent bad payment behavior and end up regularly
in the over 45 aged tracking (this might defer by market), the account will be removed
from the scope.
2) Trade and DSW invoices.
3) To the date of this review the following countries are in scope: Austria, Belgium, CEE,
France, Ireland, Italy, Netherlands, Nordics, Portugal, Spain, Switzerland and UK,
Greece and Cyprus, Germany
On a monthly basis, a report is extracted using a predefined query
(METRICS.AR_EM_ANALYTICS_DTP_PREDICTION) and will list customer numbers in line
with the requirements listed above.
It is under the discretion of the Squad Leads to keep or not determined customers in the scope of
AR Low Touch Collection, therefore the report is sent for their revision and agreement.
Controls:
Low Touch accounts are controlled as per the standard control points for the Collection
Management
Process as the Collection Units responsible of the accounts do not change in CARS.
Measurements
Low Touch accounts are covered by the standard AR measurements.

5.2. Collection Activities
5.2.1. Maintain/update Customer Information

Description
The maintenance of current information detailing Customer contact points, addresses,

references, specific requirements etc., and records of all communications concerning invoice
payment collection on the AR Database(s).
Linkage
• To 3 Call process; records of Customer reaction to the pre-invoicing call, including any
early payment commitments, rationale for payment delay, relevant comment on invoice
content or approval processes.
• To Dispute Management; identification / resolution of disputes, and use of collected data
to update Customer information on payment trends, specific or long-running issues etc.
• To the Pre-Legal AR process; Data required to support the submission of an agreed Bad
- Debt to Pre-Legal
• To Sensitive process : link to the process in QMX :
https://d01db034.pok.ibm.com/q_dir/qmx/aca/qm8pl.nsf/36de8dfc82b97ecf85256fea007bd8
b9/76fd2dd4bad346c1852583e500405950?OpenDocument&Highlight=0,sensitive
Steps
1.) Customer Record creation and updating; Responsibility of the Account Administrator or
centralized CMR group (outside of the AR Process).
CARS requires the following four mandatory fields to be available from Customer Record:
• Customer number (ICUSCNO)
• Division Code (CAGLDJV)
• Branch Code (IOLCBON)
• Collection Unit Codes (IJOBCUN)
In additional CARS requires Direct Debit information for any Customer using this method of
automatic payment. This may be from Customer Record, or may be entered directly into CARS
2.) Creation and updating of CARS / CDMS / Engage AR with Customer information.
Responsibility of the AR Collector. Within CARS / CDMS additional specific Customer
information is required such as:
• Customers AR contact points and contact data (telephone, fax, e-mail etc.)
• Customer specifics (e.g. special points about Customer sensitivities)
• Direct Debit data, including Customer Bank detail (codes, account numbers)
Collectors should use CARS / CDMS / Engage AR to maintain a history of previous call
outcomes.

Updates must be performed as soon as new information is received. These should include:
• payment practices and trends, any special terms or known issues or sensitive topics
• method of IBM collection, i.e. Direct calling and/or Arrears Letter usage
• commitments to pay
• follow-up activity linkage
• notes concerning the sending of invoice copies, statements, reconciliations etc.
• all data collected from calls/letters etc.
• add/update CARS Direct Debit database
• update Customer Record with changed credit status, i.e. Cash on Delivery
Responsibilities
- Customer Record maintenance: The Account Administrator.

- CARS / CDMS / Engage AR updating: The AR Collector.
Measurements
Not applicable.
Controls
The database should contain at least 12 months historical data at any time.
Data will be required to support the submission of any situation to Pre-Legal, so countries will
need to base periods of historical data retention on specific country legal requirements.
5.2.2. Collection Management

Description
Planning, management and performance monitoring of collection activities.

Normally this starts with the production of month-end reporting data detailing debt outstanding,
and concludes with the reporting of performance achievement at the end of the measured period.
Linkages
This activity links to all other AR process activities, and specifically impacts overall DSO,
Collection Profile and aged debt performance.
Steps/Activities
There are 3 main elements:

A) Performance planning
B) Execution
C) Performance monitoring
A) Performance planning, Responsibility of AR Collection management supported by AR

Planning and Controls.
Collection must ensure 100% coverage of all Customers (for exceptions, see below), including
Large, Medium and Low Value accounts, through Direct Customer contact (normally telephone,
but could be personal meeting as well), e-mails and/ or Arrears Letters. All Customers should be
contacted through one of these methods within 14 days of Invoice Due Date.
This general guidance is based on the WW Payment Terms (where invoice due date = invoice
date) generally followed in all European, CEE and MEA territories and therefore, the Common
Collection Plan (and tools supporting the collection process as the automatic arrear letters) are
based on this rule.
This guidance does not prevent Collection teams from contacting customers prior to the
invoice due date, in cases where exceptional payment terms have been agreed (invoice
due date > invoice date). In fact, it is recommended to do so, the purpose of which is to ensure
that an invoice has been received and no potential disputes have been already identified by the
customer. Regular collection actions would not take place at this stage where invoice is still not
yet due.
In addition a follow-up methodology must be agreed, so that the Collectors use a standard
procedure across the Customer accounts.
These procedures must be documented per Country/Collection team level as part of the
Collection plan.
Since November 2011, a Common Europe Collection Plan was implemented for all Europe IOT
countries in order to harmonize the collection initial contact and follow-up methodology. CEE
countries aligned to this Europe Collection Plan in 2012 whilst in 2014, the plan was updated to
further incorporate all countries in Europe, CEE and MEA into the same Collection Plan.
An update from November 2015 aligns the MEA Collection Plan to that of Europe ́s clip levels and
in doing so harmonizes the approach for all countries in Europe and MEA.
Since 2013, IBM’s Business Analytics Project brought yet another possibility to manage
Collections in all systems supported through the issuing of CDMS Recommendations.
Since 2017 BA recommendations in CDMS were disabled. “Watchme” widget was therefore
created to help the collectors follow up on their customers as per the collection plan.
The widget is visible in Smart AR Infocenter : https://esweb.rochny.ibm.com/sari/
The collection plan also allows for the Country AR manager or Squad leader to approve excluding
specific customer accounts from standard initial contact and the follow up actions stated in this
plan.
These exceptions should be documented as follows:
• To document a valid reason behind the exception
• To create a specific collection plan for this customers
• To review the excluded customers on a yearly basis (document and approve)

The Europe & MEA Collection plan guidance can be found in the Global CF QMX document:
https://d01db034.pok.ibm.com/q_dir/qmx/aca/qm8pl.nsf/procnum/STS-O-0976?OpenDocument
In addition, AR Planning Team generates a country level plan (split between Centre/Country
Collection teams) setting targets against the Q2C AR Metrics stated below. This plan is divided
by the Squad Lead per individual Collector (for more details on Planning see Section 5.5).
Invoices less than US-$ 35:
In an effort to improve productivity and allow to focus AR activities on more high-value receivables,
AR is not required to take active collection action on certain invoices. An automated write-off
solution for all invoices below $ 35 and an Invoice age as well as all partially paid Invoices with a
remaining balance below $ 100 (with no further adjustments performed on the AR item), will be
automatically written off after 90 days.
Due to legal requirements, the customer will continue to receive the invoice and may ask
questions, dispute, or pay the invoice.
The following situations are outside the scope for automated write-offs:
1. Invoices in dispute
2. Account or invoice(s) referred to OCA, or where collection effort is not being performed by
IBM
3. Account referred to Legal
4. Credit in process: in some countries this may be used to simply indicate that an invoice
is to be credited, but it is also used in some countries to indicate a balance that is to remain
open on the account until a Withholding Tax certificate is received
5. Direct Debit: where invoice is either manually included for DD or is included in next CARS
batch call-off
Factoring cases, either internal or external
Invoices less than 1000$ (only Trade):
The follow up activities for these invoices should be covered through the Arrear Letter program
(chapter 5.1.11) unless the invoice would be sited in a customer account classified as
sensitive/face to face where Automatic Arrear Letter program is not available (in this case
minimum collection activities as per the Country Collection Plan are required).
This specific collection plan means that once the arrear letter program has been executed the
collection process for these invoices can be defined as exhausted (go to Delinquent or Distress
process).
Customer accounts under Small Delinquent Debt (SDD):
An SDD account is defined as per the following conditions:
• Entities/Customers with only Trade & DSW

• Entities/Customers where no OCA facility is in place
• Entities/Customers with no open dispute/s
• Entities/Customers not flagged as sensitive and active arrears letter process

• Entities/Customers with current invoice balance <5k€

• Entities/Customers generating collection <5k€ per last 3 months
Note: The selection of customers will be based on entity/enterprise number.

For countries where the CMR entity/enterprise number is not in place the selection will be performed at
customer account level, being key the collector review to ensure correctness of accounts to apply the SDD
process.
SDD Standard Action Codes
SDD Collection and Pre-Legal process

SDD accounts should follow the specific Collection and Pre-Legal process:
1. SDD flagging process:
1.1 The applicable invoices suitable for SDD process and in line with the defined criteria are
indentified
1.2 The collectors review the accounts flagged as SDD:

• If an accounts needs to be removed from SDD:
The collector can decide to exclude an account from SDD process. The standard collection
process follows thereafter and the invoice(s) no longer continues to follow SDD process.
• If an account needs to be included (additionally) as SDD:

The collector can decide to include an account as SDD. The reasons to include the account in
the SDD process as well as the person (Iteration Manager or Squad Lead) approving that change
should be documented in CDMS/ Engage AR.
2. SDD Collection process
2.1 The initial contact and follow up activities have to be covered through the Arrears Letter
program (no active collection actions are required)
2.2 The collector needs to get informed of any invoice(s) with aging of 55 days that may proceed
to the next stage of the SDD process: This means that the three automatic arrear letters have
been sent and therefore the following steps should be executed.
Note: In some countries there are some specifics which would delay this step from day 55:
Countries where quarterly billings are differentiated in CARS (arrear letter program will finished around 70
days from invoice due date)
Countries with Arrear Letter process deviation in place (those deviations would affect the arrear letter
program timing and therefore the moment where the third arrear letter is sent)
3. Notification to Marketing
(not applicable for orders that are placed directly by the customer without sales involvement)
3.1 The collector sends a notification to the customer Sales representative confirming that the
final letter (described in point 4) will be sent to the customer in 3 working days unless Sales can
provide a more suitable solution to the case (ie. to confirm a payment from customer, to confirm
a meeting with customer to gather a payment confirmation, etc).
In case that the account shows any Maintenance Billing it is required to ensure that GTS TSS
Sales team is included in the Marketing notification.
This notification aims to allow Sales to provide potential alternative solutions to the case.
These alternatives will be evaluated by the Collector (the final decision is on AR). The following
alternatives will be valid:
• Marketing decides to request a cancellation of the open AR through a Claim. In this case,
the case/invoices are put into dispute.
• Marketing provides a collection roadmap to secure payment within 30 days (for recurring
billings) 10 days (for one time charge billings).
Note: The Europe Marketing notification template can be found in the QMX document Small Delinquent
Debt Handling No. STS-O-0984
4. SDD dunning letter is sent

In case of no Marketing reaction and/or:
- If the claim option was used but it was finally rejected (dispute to be closed and re-addressed
to the SDD process)
- Sales’ collection roadmap did not get the payment from customer
The Collector will send a certified letter where it will be confirmed that if not reaction within 10
working days:
1. Any open contract will be cancelled
2. The customer accounts will be flagged as COD/Black List to allow only pre-paid contracts in
the future.
Note: The Europe SDD letter template can be found in the QMX document Small Delinquent Debt
Handling No. STS-O-0984

5. COD & Contract Cancellation

If no customer reaction, the Collector will request to the PreLegal analyst:
1. To cancel any open contract
2. To flag the account with COD/Black List
Note: Contract cancellation terms can delay the resolution by up to 90 days
In case of TSS contracts: Pre-Legal will clearly state in the cancelation request that this is a
“Cancel for Non Pay” cancelation and therefore it should be processed to the date that the
customer stop paying the TSS charges (the request needs to include copy of the TSS invoices)
6. SDD Write Off request:

Once PreLegal confirms to the Collector that point 5 has been executed and any potential new
invoice and/or credit note (caused by the contract cancellation) would be already issued, Write
Off of pending any open AR is requested by the collector in AAT.
Write Off Package will include:

• Proof of active Arrears Letter Process
• Proof of Last Dunning Letter sent
• E-mail informing Marketing
• Confirmation of COD flag request
• Cancellation of contract in case of repeating charges
7. New billings issued in a SDD accounts:

In case that a new invoice would be raised in an account where the SDD process has been
executed (COD and Cancellation of contracts have been executed):
7.1 If new account balance >5K

The overall case needs to be addressed to Pre-Legal for evaluation.
7.2 If new account balance <5K

7.2.1 If the new invoice refers to a new recurring contract not covered by the SDD letter: The
SDD process needs to commence to cover this new contract (old billing already covered by the
SDD process are written off)
7.2.2 If the new invoice refers to one time charges or a recurring contract already covered by the
SDD letter: These billings will be cancelled through a SDD Write Off (to be included in initial write
off request if still not performed)
In all these scenarios: The reasons why the COD flag did not prevent that new billing should be
investigated.
Global CF QMX:
Further information about the SDD process can be found in the following QMX document:
Small Delinquent Debt (STS-O-0984):
Note: In the moment of this review, the SDD collection process only applies to Europe IOT countries.
Further analysis is on going to spread this guidance to CEE and MEA countries.

B) Execution, Responsibility of AR Collector
Collectors should perform the following activities:
• establish Customer relationships and ensure Customer adheres to IBM payment terms
• maintaining/updating Customer information on AR databases
• Contact all owned Customers within 14 days of invoice due date - either by arrears letter,
telephone call or personal meeting.
• Forecasting collections/dates for current month/quarter (see section 5.1.8)
• add/update Action Codes in CDMS / Engage AR as appropriate in current country setup
• maintaining follow-up activities (as per Collection plan)
• recording all Customer responses, commitments, queries on AR databases
• monitoring payments versus commitments
• copying invoices, statements, customer account reconciliations where appropriate
• recording Disputes in CDMS / Engage AR
• identifying Dispute Resolution Owners and notifying them.
• resolving Disputes personally where possible
• monitoring the production of Arrears letters for designated accounts
• tracking Customer reaction (payment/query/no response) to Arrears letters
• Collectors provide input to AR management on whether LPF should be aggressively
pursued for any delinquency based on management judgment considering specific criteria
and customer specific issues.
• preparing documentation for agreed Pre-Legal situations
• preparing documentation for Write-Offs
• preparing documentation for Refunds
• notifying Risk Management of distressed Customer accounts
• creating a month-start collection forecast and updating it weekly to reflect changes
• organizing physical cheque collections where appropriate
• initiate escalation processes where required
• informing management of any issues impacting prompt collection
• Raising CARS Adjustments (as per the Common Adjustment Matrix)
Additionally Collectors should encourage Customers
- to use automatic and/or electronic payment methods, such as Direct Debit, Credit Card.
- to use e-business applications available on the Web (Invoices)
Note: In case copies of invoices or statements of accounts are to be sent to the customer, it is
the collector responsibility to make sure to send this confidential information only to an entitled
customer contact. As the webtools are only accessible to entitled customer contacts, the collector
should always encourage the customer to check by themselves on-line.
C) Performance monitoring, Responsibility - AR Collection Management
AR Collection Management must monitor:
• payment performance versus Forecast

• collection coverage
Measurements
The Q2C AR Metric targets can be divided:

• Total Delinquency (TD) :
Measures the absolute $’s on file older than 30 days (AP AR calculation method).
The target represents the maximum $ amount that can be left on the file for this metric at the end
of the measured month.
Objective: Finish with a lower $ amount than assigned.
• Aged >90 :
Measures the absolute $’s on file that will be over 90 days old (AP AR calculation method).
The target represents the maximum $ amount that can be left on the file for this metric at the end
of the measured quarter.
• Aged Items (>150 days) :
Measures the line items (billed invoices, cash payments and credits) older than 150 days (real
aged, not AP AR) expresses it as a % of total line items on file at the beginning of the month and
due within the measured quarter.
The target represents the maximum number of over150 days old items (expressed as % as
defined before) that can be left on the file at the end of the measured quarter
Objective: Finish with a lower % than assigned.
In addition, complementary targets will be established:
• Unapplied Cash status: This target is under Cash Administrator scope with the Collection
support.
Objective: Finish with a lower % than assigned
• Dispute Management:
For measurements specifically related to Disputes Management see chapter 5.2
Controls
The Squad Leads or Iteration manager should perform twice a month a review of the collection
performance. The purpose of the review is to control that the collection activities are performed in
line with the collection plan. Collectors must be able to demonstrate execution of collection
activities through deployment of 100% coverage planning plus management of follow up and
escalation procedures, for both clean and disputed debt. Records must be maintained of calls
made, comments noted, follow-up actions recorded and executed, particularly for all Aged items.
When there are non compliant situations, the squad leads should follow up with the collectors to
analyze the reasons and set up action plans where appropriate. Evidence of the review must be
stored for future reference and audit purposes.
It is strongly recommended that the control executers take advantage of the existing AR Infocenter
widget, WatchMe. The widget should alert only on the collectible AR managed by his/her squad.
Global CF QMX:
Further information and the Europe AR Collection Plan can be found in the following QMX document:
EP & MEA Collection Plan (STS-O-0976)

5.2.3. CDMS / Engage AR Usage for Collection Activities
CDMS Commentary guidance

(a migration from CDMS into Engage AR is ongoing and the activities currently requested in CDMS will in the future be
performed in Engage AR
Link to the Engage AR global dispute process : https://ibm.box.com/s/qhp3ydb41ho57aovji7yvtgaitbpx3qe
For all Engage AR dispute related material : https://ibm.box.com/s/w1l2uvbxjkmvxob61cwx3c7d2sykkjm6 )
All Open A/R items should be covered as per collection plan and should include a full summary
with:
1 - Name of the person spoken to (stating IBM or Customer)
2 - Main idea of the conversation
3 - Action plan agreed
4 - Summary in English and supporting details in local language underneath.
Note: Pasting of emails/SameTime is not necessary, however it is recommended if adding significant

value.
Follow up activities
To meet Collection Plan as a minimum and support operational target achievement, ensuring
forecast is updated appropriately. Follow up dates should be in line with specific issue or
customer/internal request.
Action codes
The use of Action Codes as commentary codes throughout the Collection Process is deployed in
all countries.
The main value of the use of Action Codes is as follows:

Collectors - for communicating the status of an Invoice.
Frees up Collector's time for collection activities (instead of providing ad hoc status reports)
Enables Collector to prioritize workload more easily (by better awareness of the stage in the
collection cycle of each item)
Provides better clarity of communication to all interested parties
Iteration Manager & Squad Lead - for tracking and reporting

Clarifies reasons behind forecast probabilities
Gives Iteration Managers and Squad Leads more confidence in status reports provided to the
Businesses
Gives Iteration Managers and Squad Leads visibility of aging items that are not progressing in the
collection cycle (and enables them to move them on)
Definitions aligned to Forecast suggestion – Collection and Pre-Legal Analysts



Forecasting in CDMS / Engage AR

Should be executed in line with guidance in Section 5.1.10.
5.2.4. Distressed Account Management

Description
A distressed account is one which has AR overdue (from Due Date) and for which collection
activities have determined there is a potential customer solvency issue. These situations where
there is a potential inability to pay differ from those where there is an unwillingness to pay
(disputes, payment habits etc.), which are addressed in other process elements.
The objective of this process element is

- To early identify any potential credit risks
- To change the focus and the collection methodology for Accounts defined as
distressed.
Linkages
1. Distressed accounts management feeds the Pre-Legal process.

2. Potential use of the Debt Rescheduling solution or pre-payment as an action plan for a
Distressed Account.
3. To Global Risk Management for updated Customer Credit ratings.
Steps/Activities
a) Identification of an account as Distressed.

This is based on aged debt reporting data, should be separately identified by the AR Collector as
soon as insolvency risk is detected from various collection activities, and agreed by management.

b) Review
All Distressed accounts should be reviewed to determine an action plan to resolve. This plan
should be documented in CDMS / Engage AR.
Once an account is determined as Distressed and transferred to Pre-Legal Analyst, the account
needs to be flagged accordingly by the Pre-Legal Analyst to one of the scenarios stated in the
Common Legal flag model.
For countries pending of implementation of Common Legal Flag Model (see 5.4 Pre Legal
Administration section), different country level flags are in place to classify distress accounts.
Credit Management will identify any Distress account through the flags actioned in the AR
Systems (Credit Management may request further information to AR Collection about any of
these cases).
• The most common reason is Creditworthiness, where a Customer’s cash status changes
because of trading difficulties.
In each situation the AR Collector should check that linkage back to the relevant process
element has been made to minimize further exposure.
c) Action Plan
The following action plan has to be followed:
• Notification to ISU/Sector/Global Services Management (this notification only will be
performed in cases where the customer relevance advises the sector involvement).
• Hand over to Pre-Legal Analyst or the relevant country organization handling potential
bankruptcies cases.
Responsibilities
Distressed account identification and review and action plan creation are the responsibility of the
AR Collector together with the Squad Lead.
Controls
Distressed accounts must be documented and records retained for at least 12 months.
5.2.5. Delinquent Account Management
Description
A delinquent account is one which has AR overdue more than 90 days (from Due Date), without
outstanding dispute(s) directly related to the AR overdue, and not previously identified as a credit
/ insolvency risk (Q2C AR Distressed Account Management).
The objective of this process element is
- to identify any potential risks
- to change the focus and the collection methodology for Accounts defined as

delinquent.
Linkages
1. Delinquent accounts management feeds the Pre-Legal process.

2. Potential use of Debt Rescheduling as an action plan for a Delinquent Account.
3. For Trade cases: Late Payment Fees can be used as a tool for accelerating the resolution of
specific Delinquency cases
Steps/Activities
a) Identification of an account as delinquent.

This is either based on aged debt reporting data, and agreed by management as part of the
Delinquent Management Review / Pre-Legal Review. This identification may result in the account
being classified as Distressed (Q2C AR Distressed Account Management).
b) Review
All delinquent accounts should be reviewed to determine status and action. This should be
documented on CDMS / Engage AR with the appropriate action code. Reviews should also
assess the reasons for accounts becoming Delinquent, and take actions to prevent re-occurrence.
For example, 2 common reasons could be:
• Dispute Blackouts; Where a Customer refuses to make any payments until a specific
Dispute is resolved.
Payment Practices; Where a Customer changes payment practices (possibly following a change
of ownership).
In each situation the AR Collector should check that linkage back to the relevant process element
has been made to minimize further exposure.
c) Action Plans
The following action plans should be considered:
• Escalation to Marketing/ISU/Sector/Global Services Management.
Specific guidance for Maintenance AR as per the Global guidance “Cancel For Non Pay”
(CNP): In cases where the customer account shows over90 TSS AR caused by an active
Maintenance contract should be addressed to the GTS Sales Team previous to take any other
action.
This escalation aims to allow TSS Sales to provide potential alternative solutions to the case.
The following alternatives will be valid:

- Marketing decides to request a cancellation of the open AR through a Claim. In this case, the
AR items should be disputed.
- Marketing provides a collection roadmap to secure payment within 30 days.
In case that TSS Sales team will not take ownership of the case or the provided collection

roadmap will not secure the payment within 30 days, the AR Collection team is entitled to decide
to cancel the TSS contract since the date that the customer stopped paying the TSS charges.
The Q2C AR Collection team will evaluate with the AR Pre-Legal team if this CNP cancellation is
the most recommended solution for the overall customer’s situation comparing it with the standard
Pre-Legal options.
In case that it would be finally decided to cancel the TSS contract: the Collector will send a certified
letter where the customer will be informed that the TSS contract will be cancelled if not reaction
within 10 working days.
If no customer’s reaction is received, the AR Collector will request to AR Pre-Legal team to

request the CNP contract cancellation to the moment that the customer stopped paying the MTS
invoices (copy of the pending invoices needs to be included in the cancelation request to the Q2C
TSS team).
Note: At the moment of this review, the CNP process is under full review with TSS.
• Hand over to Pre-Legal Analyst

• Propose a documented Write-Off
• Refer the Account to Outside Collection Agency
• To issue Late Payment Fees for the current delay in payment (only for Trade AR).
Responsibilities
Delinquent account identification and review and action plan creation are the responsibility of the
AR Collector together with the Squad Lead.
Controls
Delinquent accounts must be documented and records retained for at least 12 months.
5.2.6. Deferred Payment Agreement (DPA)
Description
A sub-process designed to formalize and control delayed payments, used in circumstances where
a Customer requests a delay after receiving an invoice, or as a proposal by IBM to secure a form
of payment guarantee, where the Customer’s payment record indicates that he cannot pay on
time. Interest is added to the AR amount to compensate IBM for the delay.
DPA proposals by IBM should be a last solution and should only be done by authorized roles at
the moment an account is in Pre-Legal Review. It should not be used as part of normal collection
activities.

Linkages
1. Collection management, where identified in a payment by a Customer with cash-flow

problems.
2. Delinquent account management, where identified as a means of handling.
3. With EMEA Treasury via an automatic CARS linkage.
4. To IGF and Finance for approval as being a form of Debt Rescheduling.
Steps
a) Identification of a situation as potential for DPA.

• Requested by a Customer as a means of deferring payment after invoice receipt
(Rescheduling)
• Proposed by IBM as a means of handling a Delinquent account at Pre-Legal review.
(Rescheduling)
b) Review and approval.

Once a potential DPA is detected by the AR Collection team, it should be hand over to the AR
Pre Legal team for its review (see 5.4 Pre Legal Administration section for further description
about Debt Rescheduling/DPA option)
5.2.7. Statements / Customer Account Reconciliations

Description
The production and dispatch to Customers of monthly Statements of Account, and ad hoc
Customer Account Reconciliation reports.
Linkages
• Customer Record.
• Collection activities
Scope and Importance
CARS produces and archives monthly statements per customer account being this information
available for any customer and/or internal requirement.
The standard/common approach is that these monthly statements are NOT sent to the Customer
(CARS statement option is flagged as NO by default)
This strategy allows reinforcing on-line solutions available for all customers as Invoices where
copy of all IBM invoices are available for the customer review.
Statements should include:

• Customer Name and Address.

• IBM Customer Number.
• All Open AR items, including Invoices, Credit notes, Unallocated Cash, Debit Notes and,
where appropriate, Promissory Notes.
• All Open items to be identified with an Invoice/Reference Number, a brief description of
the revenue and invoice type, the value in the agreed currency (either Local or Euro), the
date and Due Date of each Open Item, and any partial payments.
• Details of where and how Payment should be made.
• An IBM contact name and telephone number/mail address.
• OPTIONAL; Statements can also include a record of the previous month’s
payments/movements.
Statement production is an automatic process triggered by CARS which sends data to a country
Print file.
A common functionality “AR Print System”(ARPS) is implemented in all Europe countries, except
Israel (at the time of this review, a local printing solution is in place).
One of ARPS’ additional facilities is to allow collectors to send CARS statements (and/or arrear
letters) to customers via e-mail.
For accuracy and Customer Satisfaction it is essential that the Customer details are kept up to
date at all times on Customer Record and in CARS.
Backdated Statements
Customers may request backdated statements and, depending upon the age of the records
requested, these can either be supported from CARS on-line, or by transaction history log.
On-line history records of settled items are maintained for 12 months, and archived records off-
line are maintained in a transaction history log for 10 years.
Before dispatching any requested historical records to a Customer, they should be carefully
checked to ensure accuracy. The use of such statements of reconciliation is not mandatory, and
should be treated as an additional Customer request for specific country review.
Responsibility
The production of AR statements is the responsibility of the AR Collector.
5.2.8. Consolidated Statement Facility
Description
A facility offering global customers consolidated overviews of their AR outstanding, for multiple
countries and/or in multiple currencies into one single statement, so that the client can make
one payment in the currency and country of their choice.

The procedure starts with the presentation of specific local invoices into the CSF Tool
(Consolidated Statement Facility), and stops with the settlement of the invoices on the AR
ledger in each country.
All active CSF Accounts worldwide can be found in the Consolidated Statement Facility
(CSF) community:
https://w3-connections.ibm.com/communities/service/html/communitystart?communityUuid=ef29f715-
8b5a-4c65-a28b-ac7bcb922e61
Q2C AR is the responsible, vertical organization for this process.

The CSF Process, including A/R responsibility, is owned by International Customer Fulfilment
E2E and worldwide.
Linkages
1. Collection Management. AR Collectors must be aware of any Customers who will make
payment using the CSF Offering. For each account, there is a dedicated ICF CoE global
coordinator nominated who acts as CSF lead coordinator. The ICF CoE global center is
based in Bratislava.
2. EMEA Treasury and Treasury Operations.
3. Invoicing (any invoices to be settled by CSF should be annotated accordingly).
4. Collection Management. AR Collectors to ensure no reminders are send out to the local
customer but turn back to the ICF CoE CSF lead coordinator for any questions.
Note: Global Services impose the following conditions to the CSF Customers:
- Suspension of delinquent Customers after 3 months together with cross-charging of fees to countries.
- Late Payment Fees of 1.5% of statement amount when payment is not received within 30 days.
Steps
1. Customer signs a Consolidated Statement Attachment to an IICA (International IBM

Contract Agreement) or any equivalent.
2. Contract details will be loaded to IFACTS (global repository for international contracts)
by the lead ICF CoE.
3. ICF CoE will inform all participating countries.
4. ICF CoE CSF lead coordinator makes country AR Collection team aware of agreement
and specific affected Customer numbers.
5. The AR Collector will utilise action code SECU ‘Sensitive Customer Handling’ for
invoices issued on the affected Customer numbers.
6. The AR Collector communicates any relevant invoices to the ICF CoE CSF coordinator,
immediately invoicing takes place.
7. ICF CoE CSF coordinator enters invoice data into CSF tool.
8. The AR Collector updates CDMS / Engage AR in line with the Collection Plan.
9. CSF communicates with Bank of America to obtain currency exchange rates for all
invoices to be converted into the currency choice of the Customer, and then sends a
Consolidated Statement once or twice monthly or once quarterly, depending on the CSF
agreement to the designated Customer ‘lead’ office.
10. Customer pays Bank of America.
11. Bank of America refunds local country Banks who settle the relevant invoices with IBM.

12. ICF CoE CSF lead coordinator informs all participating countries, A/R and Treasury,
about the payment to be received including local invoice numbers and amount.
13. The AR Collector adds action code APPR ‘Payment Proof’ with 100% forecast
probability setting the forecast date to the date payment is finally expected to be loaded
and visible in CARS to settle the invoice.
Responsibilities
– The CSF Coordinator is responsible to communicate any account under CSF process to
the AR collector
– Identification and communication of invoices to the local CSF coordinator is the
responsibility of each country AR Collector.
– Conversion of invoice amounts, production and dispatch of Consolidated Statements to
the Primary Customer site is the responsibility of ICF CoE, lead CSF coordinator.
– AR Collection from the Primary Customer site is the responsibility of ICF CoE, CSF lead
coordinator with ‘support’ from the AR Collector in the IBM Primary site country.
– Communication of collection status to partner country AR Collector and Treasury is the
responsibility of the ICF CoE, lead CSF coordinator.
Controls
CSF accounts are controlled as per the standard control points for the Collection Management
process.
Measurements
CSF invoices are covered by the standard AR measurements.
5.2.9. IPP
Description
IPP (Installment Payment Plans) are used for situations where Customer request advanced
billings (normally at contract approval) that result in multiple payments of invoice(s) or invoices
be phased or staggered over a longer period of time. To facilitate this IBM will add the cost of
the increased payment period as an interest to the overall contract, and agree a phased plan of
payments (normally an initial payment followed by monthly payments). All such agreements
must be proposed, calculated and approved by Global Financing. IPP agreements should be
signed and agreed by the Customer before any billing takes place. Once an IPP agreement is in
place, the following steps occur:
Steps

This may differ according to which model is used in each country; the IGF subsidiary model, or
the Division model (which has no original invoices, only installments).
1. Following shipment or the 1st billing milestone achievement, an invoice for the total
contract is issued by Billing and passed through GLIM to CARS.
2. CARS receives the invoice, (or a Debit Note from Global Financing indicating the issue
of a Loan to Customer), with some identification signifying the item is subject to IPP.
3. The local Global Financing Portfolio applications is updated with the new Agreement
which contains the capital sum to be financed, and this application calculates the Interest
amount and triggers an additional new invoice or installment through CSIM and GLIM for
this interest amount. This additional invoice is also passed to CARS. At the same time
the Customer is notified by Global Financing with the IPP Agreement which he has
committed to.
4. Both invoices or debit notes are settled in CARS by payment received from the Global
Financing Portfolio System, and replaced by new Open IPP debit entries reflecting the
staged payment plan (normally monthly) calculated by Global Financing containing the
original capital sum plus the interest due.
5. The Customer makes monthly payments which are settled against the relevant Open
IPP items.
Note: In CEE: In case that the billing feeder releases an invoice which is subject of IPP, the invoice is
updated in the LIW system by Invoicing administrator according to agreed IPP with the instalments and
related due dates. On AR side: CARS receives from LIW the correspondent instalments with its own due
date as per agreed IPP without additional actions needed in CARS.
In Turkey there was an agreement reached, where for the CuF procedure manual IPP adjustments are
performed in CARS.
Responsibilities
IPP Agreements are the overall responsibility of Global Financing.
Controls
All IPP Agreement transactions must be fully supported by documentation. Any change to the
payment schedule or to the contract terms must be referred back to Global Financing for
approval and re-calculation where appropriate
5.2.10. Forecasting
Definition
The Forecasting process is to be used by AR Collectors and Squad Leads as a key part of the
overall Accounts Receivable Process. AR Collectors have a responsibility to forecast their AR
backlog (Open Items; invoices, credit notes, unapplied payments and dishonored payments)
every month in order that AR Management is provided with an up-to-date awareness of the
expected Cash Collection performance.

In addition, Squad Leads can use the forecast information to ensure that resources are sensibly
deployed to achieve the optimal Cash Collection results, and to report expected Cash Collection
to various levels of management within IBM, including IMT/ IOT, the geography and corporate
headquarters. Cash Forecast is a key tool for Corporate Management to enable key EMEA
Treasury decisions to be made in advance of each quarter end.
Scope
The scope of the Accounts Receivable Forecasting Process includes the following activities:
 Review of Prior Month’s Forecasting Results

 Management Identification of Current Month Forecasting Targets at an Individual A/R
Collector Level
 Creation of Forecasts for Current and Future Months
 Maintenance of Forecasts for Current and Future Months
 Assignment of Probability of Payment Receipt
 Month-end Closing Activities
 Month-end Recording of Forecasting Performance
 Automated Forecasting
Link to Overall Accounts Receivable Process
Accounts Receivable Forecasting, together with Accounts Receivable Collection Planning,

Dispute Management and Ongoing Performance Management, form key elements of the overall
AR Debt Collection Process, which is separately documented in the Accounts Receivable
section of the Finance Portal.
It is also part of the specific country and geography Accounts Receivable Forecasting
Management System. This could differ based on the specific country and geography
headquarters measurement requirements
Steps
1) Collection management reviews and assesses the previous month’s forecast/collection

results. This is done at both a unit and individual A/R Collector level.
2) Where the Automatic Forecasting functionality is not utilized, A/R Collectors review each
open item in the invoice database that is assigned to them. Each collector edits the open AR
item in CDMS / Engage AR with the forecast value, the date settlement expected, and the
forecast probability.
The different forecast probabilities and their correspondent definitions were established at
Global level in July of 2011 to ensure a common understanding of the different forecast
percentages in all Global regions.
CDMS : Forecast percentages and definitions:
100%

(i) - Confirmation from the customer that the invoice has been approved and they commits to
pay via electronic means (i.e. EFT, bank transfer, AFTP, Direct Debit, etc.) with a firm payment /
value date no later than the final day of the forecasted month..
(ii) - Confirmation from the customer that the invoice has been approved and that a check will be
mailed by no later than the last 2 weeks of the forecasted month
(iii) - Payment received
(iv) - Commitment from billing function or other IBM functions of adjustment processing - G/L
codes in process/received
(v) - Commitment or confirmation from billing function that cancellation credit note in process(i.e.
where the dispute is solved & closed during a given month, (so no longer in disputed status) or
have been processed (to be received in AR system) and if appropriate and a credit note will
settle the o/s invoice in the current forecasted month as well.)
Note: It is possible that some two or more of the above events may occur (ie, payment confirmed or
received; check approved/mailed for open balance remaining, based on resolution of dispute; credit note
is forthcoming for a portion)
75%
(i) - Confirmation from the customer that the invoice has been approved and that a check will be
mailed by no later than the last week of the forecasted month
(ii) - A customer has a very sound payment history with IBM and always pays. We can come to
this conclusion thru in-depth collector account knowledge or we may know that the customer
uses an automated system set up for payments and always pays a set of invoices on a certain
date.
(iii) - Customer or Business/IBM internal contact tells us that the Invoice is approved but
customer has not given us a firm payment or value date.
(iv) - Customer has told us payment is in progress but has not given us a firm payment or
release date yet.
(v) - Verbal/written confirmation of payment this month from the customer but no actual pay date
or value date given.
(vi) – Invoice in dispute but resolution confirmation is received from DRO.
50%
(i) - Customer tells us that a check has been mailed in last 3-5 days of the forecasted month.
(ii) - Customer has not informed us of any issues but based on account knowledge we think
there could still be risk associated with the payment.
(iii) - Customer has already confirmed the payment date but collector's previous experiences
with the client show a high probability that the customer does not fulfill its commitments
(iv) - Invoice in processing (pending approval) and no known issues/dispute are identified, but
we have no firm payment date.
25%
(i) Based on customer knowledge of the account, payment is possible, but past history
indicates it is highly unlikely to happen.
(ii) Disputes have been very recently resolved but we are not expecting payment/credits in the
forecasted month and AR needs to pursue collection activities very shortly.
(iii) Customer's AP process is lengthy / complex and requires escalation for payment within the
month
(iv) – Invoice in dispute and no resolution confirmation from DRO received yet.
0%

(i) - Based on communications with the customer, customer payment history and/or account
knowledge we know that there is no way the customer is going to pay us in the forecasted
month.
(ii) - New invoices that are due but may have been issued late in the month which might not
have reached the customer's A/P system yet.
(iii) - Billed Not Yet Due invoices where there is no hope that the customer might consider
paying them early.
(iv) - Invoices where no collection activity has been initiated
(v) - Collection preparing necessary documentation to engage or transfer to Legal/ Pre-Legal /
Special Handling
Engage AR : Forecast percentages and definitions:
3) A/R Collector reviews open A/R Items with Automatic Forecasting updates. Where items have
been automatically forecasted by CDMS / Engage AR, the A/R Collector reviews the data entered
(forecast date, amount and probability), and modifies it as appropriate. Invoices can only be
automatically forecast if they are in Open (Initial) or Disputed Collection Status. Forecasting is not
allowed for invoices in Legal, or OCA (with an Outside Collection Agency) Collection Status as
recorded in CDMS / Engage AR.
4) As the month progresses, new items are added by the upstream systems, and the AR Collector
receives new information from Customers and from related AR activity (such as the solving of
disputes, raising of credit notes, receipt of payments, settlement of Open items), he/she continues
to record the expected Cash Collection attainment by updating existing forecasts or by creating
new forecasts for previously unforecasted items.
Forecasts must not be deleted but instead they can be modified as many times as necessary
when no longer appropriate.
When an AR Collector or DRO closes a dispute in CDMS / Engage AR, a mandatory trigger will
remind him/her to make a forecast on the open item.
Overdue Forecasts
Additionally the AR Collector needs to check daily for any items where the Forecast has
become overdue. These items will be identified in CDMS / Engage AR. These items may
need follow-up activity with the Customer to understand why a payment has not been
received or within IBM to understand why a settlement has not been completed.
Dependent upon the outcome of the follow-up activity, modification to the existing Forecast
(Amount, date, probability) may be required.
System Driven Forecast Changes

As the calculation for the automated forecasting may be dependent upon the invoice due
date, when this has been changed upstream of CDMS / Engage AR, the forecast date will
also change in CDMS / Engage AR.
Where items are re-instated in CARS as a result of modifications to previous settlements,
they may contain past due invoice dates or invoice due dates. This could result in past
due automated forecasting dates (immediately overdue), which will need to be reviewed
and modified by the AR Collector

5) Management reviews the forecast information to date. Using this information, management
can reset priorities for A/R Collector on an invoice, customer or A/R Collector level. These
priorities are used to maximize the cash collection activities during the month.
6) AR Management continues to review the forecast through to the month/quarter end. Based
on the forecast information, updates can be requested to the forecast data on an individual
invoice level, priorities can be set or changed. At month end the final forecast position is
recorded in the application IW for reference.
Creating and Updating Forecasts in CDMS / Engage AR
1. Forecasts can be created or updated at any time of the month by using Edit Forecast in
CDMS / Engage AR.
2. Closing a Dispute will automatically trigger the raising of a new forecast.
3. Forecasts can be made in Local or Original Currency.
4. At month-end the closing Forecast situation will be recorded in the CDMS IW.
5. will be retained even when an item becomes disputed.
Automatic Forecasts in CDMS
The objective of Automatic Forecasting is to allow those countries with high volumes of invoices
to easier organize time on Collection. Automatic Forecasts help to concentrate on those invoices
which need their forecast adjusted rather than to be forced to enter an individual forecast for each
invoice.
AR Management in countries can take advantage of Automatic Forecasting functionality built into
CDMS 1.3. This allows countries to pick from the following options:
1. No automatic forecasting. (continue to forecast all items manually).
2. Automatically forecast all items to be settled by Credit Card. *
3. Automatically forecast all items to be settled by Direct Debit. *
* These options can be selected together or separately.
Automatic Forecast Settings.
Value: CDMS will automatically forecast the Actual Amount of the item to be collected.
Probability: The country can decide which Probability to assign to automatically forecast
invoices. For example, Credit Card/Direct Debit invoices should have an automatic forecasting
probability of 100% or Firm.
Date: Where any automatic forecasting is selected, the CDMS Country Administrator sets CDMS
to calculate the forecast date based upon the country decisions on timing of forecasting in relation
to either invoice due dates or to invoice dates. For example the country can decide to forecast all
items to be settled by Credit Card 30 days from the invoice date, or 15 days from the invoice due
date.
Payment Schedule Dates

Where CARS is the feeder for CDMS, and the function of Payment Schedule Dates is utilized
within CARS, this date will be fed to CDMS and used to set the Automatic Forecasting Date. If

the Payment Schedule Date changes in CARS – the automatic forecast date in CDMS should
also change.
Items which have been forecasted display icons in CDMS, identifying which method of forecasting
has been used (manual or automatic). This is designed to help the A/R Collector and the Squad
Leads.
Month End
At month-end all forecasts – whether overdue or not – will be retained by CDMS for use in the
following month.
Forecasting of invoices in dispute

All invoices in dispute shall be forecasted at 25% to earliest next month, until resolution
confirmation from DRO is received (e.g: credit rebill, customer accept to pay…), or after the
quarter end if there is no outlook during the current quarter.
Once resolution confirmation is received from DRO, then forecast should be moved to 75%.
Responsibilities
The AR Collector is responsible to make and update a forecast for all invoices in on his/her ledger
(including invoices which are not yet due).
The Squad Lead is responsible to review and monitor the forecast against the targets and plans
for the current month.
Controls
AR Management should ensure forecast quality through the operation reviews and collection
result analysis.
5.2.11. Late Payment Fees

Late Payment Fees are also referred to as Late Payment Charges.
5.1.10.1 Description
The objective of Late Payment Fees is to motivate and encourage customers to pay on time
according to the payment terms agreed in the contract, and to positively impact the payment trend.
In principle, Late Payment Fees invoices have to be treated like ‘normal’ invoices and are part of
any collection activity. It should be emphasized that the objective of LPF’s is that they should be
used as a selective additional collection tool for Customer Accounts which have become regularly
delinquent. In case the customer refuses to pay the account has to be handled in line with the
Delinquent process or Dispute Management Process. The dispute has to be flagged with X2
(Customer does not accept IBM payment Terms) and assigned to the responsible OO/ Sales
Relationship Rep.

Since the Corporate Instruction FIN180 review on May 2010, the Late Payment Fee Management
approach changed for Trade invoices.
The old LPF management process is maintained for Global Financing business as IGF is out of
the scope of the new LPF guide lines described in FIN180.
Therefore two different management approaches are in place:
5.1.10.3 LPF Management process for Trade:
a) Trade LPF process management: LPF Calculation and Clip Levels
The late payment fee rate charged should be a minimum of 2% per month (24% annually), unless
there is a local legal reason for a different percentage in which case the rate must not exceed the
maximum allowed by local law.
When levied the late payment fee is calculated as follows:
INVOICE AMOUNT (incl. VAT) x NUMBER OF DAYS LATE x DAILY LATE PAYMENT FEE RATE
(annual rate/365 days)
The Number of Days Late is the difference between the Invoice Due Date and the issue date of
the late payment fee invoice to the customer minus 30 days of grace period (for due upon receive
invoices) minus days in dispute (for all invoices).
This 30 days grace period is not stated in the FIN180 but it does not mean a deviation from this
Finance guidance as it allows starting the LPF calculation in the moment that Q2C understands
as the most appropriate moment.
In Europe, the 30 days grace period is a standard clause attached in the BAU contractual payment
terms and therefore it is an element to be taken into account in the LPF calculation.
It might be found contracts with different grace periods stated in their payment term clauses. In
those cases the specific grace period stated in the contract should be applied.
This new calculation formula cannot be supported by CARS (as needed to maintain the current
LPF set-up for IGF business). Therefore, any Trade LPF would be manually calculated and
requested to the Invoicing systems by the LPF Administrator role.
b) Trade LPF process management:
Following the Corporate Guidance FIN180 which is complemented through the Worldwide CSO
guidance for Late Payment Fees, while the LPF right is maintained and stated in the IBM contracts
and invoices, decisions to leverage and aggressively pursue collection on late payment fees as a
means to accelerate payment are made by Customer Fulfillment Management (the AR Country
Manager or delegate) in conjunction with Client Team Management on a case by case basis.
Consideration should be given to the following in making that decision;
1. Are LPFs specifically excluded from the client's contractual relationship with IBM?
2. Is the delinquency based on a dispute regarding performance or delivery of product?
3. Is this an isolated delinquency in a normally good paying customer or does this customer
consistently maintain significant delinquencies?

4. What is our past experience with this customer regarding late payment fees? Have they paid
them and/or were they successful in accelerating payment?
5. If late payment fees are aggressively pursued and the customer refuses payment, what is
our recourse? Cancellation of service? Legal action? Are we prepared to take these actions?
6. What other options have been considered? Executive level collection call? Notice of
cancellation? COD?
7. Is the Client Team Management in agreement on Fulfillment's approach to pursuit of late
payment fees?
Late payment fees may be leveraged and aggressively pursued for any delinquency based on
management judgment considering the above or other customer specific issues.
An analysis should be conducted on a quarterly basis to identify enterprises with over ninety day
delinquencies in excess of $500K. A review of potential leverage of late payment fees should be
documented for those accounts using at minimum the above criteria. In the interest of productivity
and cost effectiveness, no documentation of late payment fee collection efforts is required for
delinquencies that do not meet these criteria.
Further guidance is documented in Global CF QMX:

LPC Invoicing and Crediting - Manual Process DLP (STS-O-2450)
https://d01db034.pok.ibm.com/q_dir/qmx/aca/qm8pl.nsf/procnum/STS-D-2450?OpenDocument
c) Trade LPF process management: Exclusions
If countries wish to exclude altogether certain Customers from Trade late payment fees - such as
government/public sector accounts - approval should be obtained from the IOT and country CFO.
Records of these exclusion approvals must be maintained for audit inspection.
d) Trade LPF process management: Canceling or Crediting raised LPF invoices
Cancellation by credit note of any LPF invoices is applied if it has been generated by error, that
means:
- original invoice under dispute but not flagged in CARS
- "sensitive account" flag not updated in CARS when customer has exception status
- customer contract signed with special terms
- error in the calculation
Once issued, cancellation by credit note of any LPF invoices must be formally approved in
advance by the Squad Lead subject to country Powers Reserved for the approval of Credit Notes.
Requests from Marketing/Sectors to cancel LPF’s cannot be processed without additional

approval from the Squad Lead. In addition these credits should be charged back to the Marketing
Unit/ISU.
Write-off applies after review and justification, when all collection activities have failed and no
alternative action is suitable or possible. Approval for Write-Offs must be according the defined
process under chapter 5.3.5 of this document.

From October 2013 onwards, all Late Payment Fees shall be written off by CARS General
Ledger Adjustments, using local Accounting Codes provided by AR Accounting. The CARS Set
Up shall enable Collectors to perform GL Adjustments and support LPFs in the BAU write-off
process.
General Ledger accounts to be used:

Trade LPFs: GL account 02-902-0100
This is in accordance with Accounting instruction https://w3-

connections.ibm.com/wikis/home?lang=en#!/wiki/Wdcc5cece206c_4e08_9127_1e0bf13a1318/page/AI-
AR-2%20IBM%20IGF%20Accounting%20Treatment%20of%20Late%20Payment%20Feeswhich states:
‘’If an LPF invoice needs to be written off (due to expected uncollectibility), the below Accounting
process needs to be followed:
1) Preparation of LPF write-off request to be done by AR Q2C’’
2) Mandatory approval of LPF write-off request by Accounting in case the defined clip levels are
exceeded (HQ Trade A/R Analyst for Write-off amounts between $100k and $500k per customer,
HQ Director of Accounting for Write-Off amounts above $500k per customer)’’.
Responsibilities
LPF control and production are the responsibility of the AR LPF Administrator role, with assistance
from the Invoicing Operations function.
Measurements & Reports
Trends should be monitored to ensure WWPT’s are being followed, and to assess impacts on
payment practices.
Controls
Countries must document all LPF Exclusions, and be able to demonstrate numbers of accounts
excluded against the total active Customer base.
Trade cases only: An analysis should be conducted on a quarterly basis to identify enterprises
with over ninety day delinquencies in excess of $500K to review the potential leverage of LPFs
as a means to accelerate the customer payment.
5.2.12. Arrears Letters

Description
Arrears letters are formal communications from IBM to our Customers highlighting outstanding
invoices, reminding them of our payment terms, and alerting them about penalties that could arise
from late payment. They are an integral part of the Collection activity and as such, must be used
intelligently and after careful planning to ensure the maximum impact is obtained.

Each month all Customers with outstanding debt should be contacted either by telephone call or
by Arrears Letter. However it is expected that customers are by default subject to automated
arrears letters, excluding selected “sensitive” customers.
The procedure starts with a planning activity to determine usage in a specific period, and finishes
with either payment or transfer of the account to a pre-legal situation.
Arrears Letters are also known as Dunning Letters.
Linkages
1. Collection Management planning activities.

2. Late Payment Fees are referred to in the letter texts.
3. Customers who do not respond to Arrears Letters may be selected for the Pre-Legal
procedure.
4. Customers who respond to Arrears letters with invoice queries may be entered into the
Dispute Management process.
Scope
A common functionality “AR Print System” (ARPS) is implemented in all Europe countries (at the
time of the release of this document: except for Israel, where a local printing solution is in place).
Common approach supported by ARPS is that arrear letters will be issued based on any overdue
invoice.
CARS supports two levels of Arrears Letter activities:
a) Selection based on overdue Customer accounts (i.e. an account with a balance containing an
amount overdue for payment to IBM).
b) Selection based on any overdue invoices (common approach to be used).
Once ARPS is implemented any country using option “a” will be aligned to the common approach
(option b)
There are 3 phased letters:
Letter 1. To remind the Customer that Payment is due.

Letter 2. To warn the Customer that Late Payment Charging will commence if Payment for
outstanding invoices is not received in accordance with agreed terms.
Letter 3. To advise the Customer that Late Payment Fees have commenced, and that the
account will be passed to IBM’s legal representatives if Payment for outstanding invoices is not
received within a specified timeframe.
Copies of the three draft letters can be found in Appendix B (Arrear Letters Examples).
They have been updated in order to align their wording on LPF management.

Wording of the letters should only be changed for legal, fiscal or contractual reasons. An
example of this would be a Government Customer who IBM still wants to dunn via arrears
letters, but for which our agreement specifically excludes Late Payment Fees being charged.
For any substantial change to the wording prior approval from legal should be obtained.
Since 2013, the common ARPS functionality also allows to send CARS statements (and/or
arrear letters) to a customer’s e-mail.
Timing
For all invoices Due upon Receipt with Late Payment Fees if unpaid < 30 days
• Letter 1; 10 - 14 days after invoice/invoice due date

For all invoices Due upon Receipt with Late Payment Fees if unpaid < 60 days
(Normally recurring billing of maintenance and software)

For all invoices with agreed 30 days Payment Terms with Late Payment Fees if unpaid < 60 days.
(E.g. applies to specific agreed Business Partners where no country Commercial Financing)
• Letter 1; 15 - 19 days after invoice date (pre invoice due date)*

• Letter 2; 40 - 44 days after invoice date (10 -14 days after invoice due date)
• Letter 3; 68 - 72 days after invoice date (38 - 42 days after invoice due date)
Exact timing can be table-set by countries, but should always follow this cycle of 3 letters.
However, Letter 1 should not be sent any later than 14 days after date of invoice for all invoices
with payment Due Upon Receipt.
Note: Arrear Letter timings are differentiated only as long as billing upstream data flow sends parameters
to CARS to differentiate these invoice types. If this data is not received in CARS (differentiation is not
possible in CARS), the timing used as standard for all invoices is the one for invoices Due Upon Receipt
with Late Payment Charges if unpaid < 30 days.
Note 2: Shorter Arrear Letter timing programs are accepted as no process deviation to cover the need of
the countries where it is required a faster letter program to be aligned to the customers’ payment behavior
Steps
1. AR Management decides which Customers are not to be covered by Arrears Letters

(basically all customers are by default expected to receive arrears letters).
2. The AR Collector ensures that the Arrears Letter indicator for these Customer Accounts
is set to N in CARS.

3. CARS identifies any overdue invoices on a daily basis and verifies if an Arrears Letter is
required.
4. CARS identifies which letter is required based upon invoice due date and previous letter
sent..
5. CARS gathers the data, and generates a letter which, at country choice, is sent either
automatically to a printer (for onward transmission to the customer), or to the CARS Letters
Database for validation and printing.
6. CARS is updated to show the last letter type and date sent at invoice level.
A further modification of CARS ensures that, after consolidation, only one letter per letter type is
produced per day, to prevent the Customer receiving several of the same letter type with only 1
invoice reference on each letter.
Exclusions
CARS does not produce Arrears Letters where any of the following apply:
 at customer level:
o the arrears letter indicator is set to ’N’ (screen CC)
o the sensitive customer indicator is set to ‘Y’ customer (screen CC)
o the customer has been referred to an outside collection agency (screen CP)
o the customer is in receivership or liquidation (screen CP)
 or, at invoice level:

o the invoice is in dispute (status code X), or has been in dispute less than n days ago (n
is determined by country via CMOD$54)
o a credit note is in process for the invoice (status code C)
o the invoice is referred to outside collection (status code O)
o an advance remittance or future-dated cheque has been set up for the invoice (status
codes A,F,*)
o DSW autorenewal invoices (revenue type DSA) have a specific letter sent to the
customer informing them that they have to pay only if they are interested in renewing the
licence
Responsibilities
Production and monitoring of Arrears Letters is the responsibility of the AR Collector.
Ad Hoc Letters
Collectors can use other forms of letters for aiding collection from the Customer. CARS will store
specific text letters which can be called up and amended as appropriate for specific occasions as
agreed with the management.
Measurements

CARS and CDMS / Engage AR maintain records of the automatic arrear letters
Manual arrear letters should be documented as any other collection activity in the correspondent
Comment field in CDMS by the AR Collector.
Controls
CARS and CDMS / Engage AR are able to demonstrate which customer accounts receive arrears
letters and maintain records of previous letters sent. Arrears letters do count as performed
collection activity (from a Business Controls perspective), but where a customer has made no
response to any arrears letters, Collectors must be able to demonstrate that further action has
been triggered through use of the delinquent account review.
5.2.13. Factoring
Description
There are 3 types of Factoring:
a) Internal Factoring.
This is the transfer of AR Risks and Rewards to IBM United Kingdom Financial Services Ltd.
The country maintains responsible for AR collection, the debt remains in CARS & FDW, but is
on Balance Sheet for U.S. Accounting, and Off Balance Sheet for local (country) Accounting.
The decision to use Internal Factoring is taken by Treasury, and all identified invoices are
flagged in CARS (status field) for accounting/reporting requirements.
Internal Factoring contracts, at the time of release of this version of this document, are available
for United Kingdom, Netherlands, Germany, Belgium, France, Spain, Italy, Switzerland, Sweden
and Denmark.
Based on a schedule that is prepared each November for the following year by the Credit
Analyst, AR focal point provides the Opening balance of A/R, New receivables, Collections,
Write-offs and Closing A/R balance on the Exhibit H spreadsheet.
This allows the Credit Analyst to cross check the aging report details and helps to calculate
aging percentages as part of the pricing reviews every 6 months
The Exhibit H spreadsheet information is also used by both the country accounting and
Treasury Centre accounting teams to input accrual information to the ledger at the beginning of
each month.
Global EM QMX:
Further information can be found in the following QMX document.
AR_EMEA_Internal Factoring No. STS-D-2889:
https://d01db034.pok.ibm.com/q_dir/qmx/aca/qm8pl.nsf/36de8dfc82b97ecf85256fea007bd8b9/6
65b737735bbe24a852580750015bf34?OpenDocument&ExpandSection=2%2C5#_Section2
b) Commercial Financing (also known as Inventory Financing/ CoF).

This is the financing of specific Business Partner AR by Global Financing. The full agreement and
process is part of an established DOU between IGF, S&D & Q2C.
The relevant invoices information is passed from the billing system via GLIM to the Global
Financing remarketing application (usually IRFS) and as well to CARS. The original invoices are
settled in CARS by a payment file received directly from IRFS. The invoices need to be identified
in CARS to avoid inappropriate collection activity (the current systems setups show various ways
of this flagging with also potential manual intervention necessity).
Where a dispute remains unresolved and outstanding, in total or in part, for more than a number
of days as agreed from time to time between IGF and IBM, IGF will transfer back the invoices to
mainline. In addition IGF must provide notification of reassignment to IBM and Q2C AR 60
calendar days prior to the proposed invoice reassignment date. This means that the invoices are
re-opened in CARS and Collection responsibility is taken over by Q2C AR.
Commercial Financing Process

Billing &
Invoicing of
an CoF
invoice
IGF
Receive invoice in
receive invoice in
CARS
IRFS
IGF initiate If necessary as

payment (via wire per country setup
transfer or flag invoice as
settlement CoF related
interface)
Cash
Application to
settle
invoices
1. Upon creation of an CoF subjected invoice, the information is passed to IRFS and CARS
2. In case of necessity based on the current country setup, the received invoices have to be
flagged accordingly in CARS
3. Upon initiation of payment or settlement interface by IGF the money is received within
Q2C AR. This will be by Automatic settlement interface from IRFS – which needs to be
initiated and potential errors occurring within auto-allocation have to be fixed
Note: In November 2014, COF Process Reinforcement guidance was published to clarify the process
between Q2C AR and IGF CoF teams.
Global EM QMX:
Europe CF AR & IGF COF Process Reinforcement (EM-PCD-02357):
https://d12db054.portsmouth.uk.ibm.com/q_dir/qmx/em/qd8dl.nsf/procnum/EM-PCD-02357

Commercial Financing Dispute Management Process
IGF CoF
collection
Process
IGF Intentifies
Business Partner
Dispute
IGF Initiate
Dispute within
CDMS (on open or
settled items)
CF AR Focal
Point/ Collector
validate dispute
Is the Dispute correct &

No enough information
available?
Yes
IGF CoF
collection Assign Dispute to
Process proper DRO
Continue
BAU Dispute
Management
Process
1. Upon identification of a Business Partner Dispute within the Collection Process, IGF initiates
a Dispute within AMT (IGF owned system).
This may be on either open or on settled items, depending on whether the settlement to CARS
has already commenced or not.
IGF has to sent a daily report with new disputes registered in AMT to AR focals assigned. These
focals use the report to record the new disputes in CDMS / Engage AR through an automated
solution (system robot, owned by IGF for CDMS countries).
Note: CoF disputes have to be identified in CDMS / Engage AR by using the dispute local codes C1 and
C2
2. The chosen Q2C AR focal point for CoF Dispute Management or the Collector in charge of
the customer account in CARS validates the information that has been logged within CDMS /
Engage AR
a) If the information indicates a real customer dispute and are sufficient for the DRO
to start with the resolution of the dispute, assign the dispute to the respective DRO
and continue with BAU Dispute Management

b) If the information does not indicate a real customer dispute and / or is not sufficient
for the DRO to start with the resolution of the dispute, reject the dispute and inform
IGF accordingly
In the above mentioned cases where a dispute might be initiated by IGF on an open item within
CDMS / Engage AR, the dispute might get closed during its lifetime by settlement from IGF to
IBM although the situation might not be resolved. For reopening of this dispute IGF sends a report
to Q2C AR for identification of these situations. The focal point / Collector within Q2C AR is
responsible for these re-opening actions.
Note: In parallel to the AMT solution, an automatic report with the information of any dispute closed or
refused is sent from Q2C AR to IGF (in this moment that confirmation is manually done by the Q2C AR
Dispute Manager).
Responsibilities
The Collection, as well as Dispute Identification (and dispute initiation within CDMS / Engage
AR) responsibilities reside with IGF.
The Dispute Management responsibility resides within Q2C AR Collection team.
The Cash Allocation (and clarification of any payment line) of the financed payment (known as
“B2A payment”) received from IGF CoF to CARS reside within Q2C AR Cash Administration
team.
To control and work in the clarification of any open item in the reserved CoF CARS accounts:
Q2C AR (the Q2C AR country focal (usually the Collector in charge of the Dispute Manager
role) & IGF CoF
c) External Factoring
External Factoring is the sale of specific IBM invoices to an external agency under a contract for
the purpose of AR collection and is normally sold without recourse.
Note: Corporate Treasury approval is not required for external factoring directly handled by Special
Handling Group as the course of recovery for bankrupt or bad debt AR.
External Factoring (including but not limited to invoice factoring, third-party supply chain
financing, Buyer Initiated payments, etc.) of A/R is not part of the global standard payment
terms. Approval to use an external party for Factoring/3rd party early payment programs of A/R,
must be sought in advance from Corporate Treasury. For A/R External Factoring, each business
case must follow AP35 – Transfers of Receivables to Unrelated Third Parties and any request
/business case must be managed through Europe Treasury (Deirdre Boydl).
If any transaction document (e.g., SOW), non-disclosure agreement, or other related contract is
signed after the original CRA that negates the ability to factor, a waiver must be signed by the
client.
Any exceptions to this process must be approved by the applicable regional Treasurer (Deirdre
Boydl).
Customer authorization to factor receivables:

https://w3-
03.ibm.com/ibm/documents/corpdocweb.nsf/ObjectFileDocView/AUTHORIZATION+TO
+FACTOR.docx/$File/AUTHORIZATION+TO+FACTOR.docx
Steps
1. All invoices agreed for any form of Factoring/Financing must be identifiable in CARS.
2. For External Factoring, a Daily/Weekly or Monthly file reflecting invoices to be factored
according to the agreement between IBM and the Factor has to be created based on the criteria
selected: Customer number, revenue type, payment method.
This activity has 2 purposes:
- to provide the Factor with invoice information (summary data and invoice copies).
- to remove the selected invoices from open status in CARS passing the information to
accounting.
3. Depending on the Factoring solution, the invoice should be either closed in CARS as paid or
flagged as “factor” (a country level flag should be in place).
Although the invoices may be settled in CARS, the AR remains on the ledger until a payment is
received from the customer according to the terms of the agreement with the Factor.
4. For any External Factoring without recourse, and IBM acting as collection agent for the factor,
a cash transfer to the Factor is to be initiated only after IBM received cash from the original
debtor.
5. For any External Factoring with recourse, any invoices which become queried or disputed
should be recovered from the Factor, reloaded in CARS (by changing attributes, or by invoice
credit/re-bill) and adjusted in accounting reconciliation files (by reversing the original
settlement). This does not apply to External Factoring without recourse.
Responsibilities
Execution of Factoring is the responsibility of the AR Cash Administrators as per instruction and
information received from EMEA Treasury.
Formatted: Indent: Left: 1,4 cm, No bullets or numbering

5.3. Dispute Management
5.3.1.5.2.14. Definition
As a result of a Global initiative on Dispute Process alignment, a revised Global Dispute Definition
has been deployed:
‘’Client identifies an issue due to any unmet client requirement or expectation that results
in the client’s refusal to pay, short payment, delayed payment or non-payment of any
invoice or credit created by IBM that has an impact on client satisfaction and IBM’s cash
flow.’’
A dispute has 2 important elements:

1. The client has identified a problem with either the physical invoice/credit note issued by
IBM (accuracy), or with the goods/services provided by IBM to which the invoice relates
(validity).
2. This issue cannot be answered / explained by AR either immediately or to the client’s
satisfaction, and until resolved the client cannot / will not authorize payment of the invoice
(in rare cases, a client may pay an invoice and still dispute its accuracy or validity).
Therefore Dispute Management (which starts when a dispute is raised under the above
conditions and ends with the closing of the dispute in CDMS / Engage AR) within the overall AR
process is a vital sub-process with regards to both, cash flow and customer satisfaction.
Resolving a dispute offers us the chance to make this event for the customer a positive
experience with IBM. Therefore disputes must be handled immediately, efficiently and
effectively. It is imperative that the Common Dispute Management Process is deployed and
committed to by all Business Units, as it can involve any personnel who are part of IBM’s
transactions with our Customers.
A dispute must not be recorded if the client is unable to pay due to financial difficulties. Standard
collection process has to be followed including pre-legal and legal actions as appropriate.
Disputes can be received from Customers directly by telephone, fax, letter, e-mail or indirectly
by communication from any IBM employee who has received information from the Customer. In
some cases disputes can be also identified internally without any communication from the
customer.
Each dispute must be raised in the Dispute Management System (usually CDMS / Engage AR)
for any Accounts Receivable item (invoice, debit note, credit note, LPF invoice) whenever IBM’s
assistance is required by the customer or Business Partner to enable him to accept and finally
settle the AR item. All disputes are validated by the Collector who either opens it directly in
CDMS / Engage AR himself or receives Registered Disputes from Dispute Initiators, and
subsequently in both scenarios assigns it to the correct Dispute Resolution Owner (DRO)
selecting the appropriate official Dispute Reason Code (see Appendix A).
Each new dispute will be given a unique Dispute Identification Number. This number can be
relevant for one AR item or for several related items, which are subject to the same Customer
query and dispute reason. Each AR item within a dispute will have the same Dispute Reason
Code.
Conditions to log AR items under the same dispute are:

• All AR items are on the same enterprise / VAT number – though 1 dispute could possibly
include AR items of different Customer Numbers.
• DRO is the same for the dispute resolution of all AR items
• Dispute Reason Code is the same
All countries use the Common Dispute Reason Codes listed in the Appendix A of this document.
These codes will be tracked and used for Trend Analysis on a European level by the Europe
Accounts Receivable Dispute Management Leader and at country level by the AR management.
In principle no additional codes should be added, although the use of Local Codes - defined
underneath the WW Common Dispute Reason Codes - is encouraged to specify additional detail
if needed for root cause analysis. Certain WW Codes mandate the use of Local Codes. This local
coding can be added for specific country use only. For all updates on these Local Codes, the
Europe AR Process leader has to be informed.


Linkage to collection activities:
- Collection Process:
Whilst a dispute remains open, the outstanding debt is not collectable, the arrears letter and LPF
process is suspended for the disputed items, and normal collection techniques cannot be used.
Once a customer accepts that a dispute is resolved and closed, the AR item(s) becomes
collectable and regular collection activity resumes. If a dispute is to be resolved through a credit
note or write-off, documented approvals will be required in accordance with IBM guidelines.
- Complaint/Claim Management Process:

1. Process in case of dispute resolution through Internal Claim Process:
Where a dispute becomes a formal Customer complaint (classified as a country Top A/R dispute
significantly impacting Customer Satisfaction), Q2C should ensure the customer’s Client Manager
is informed so that he/she can ensure the situation is also recorded in the Claim Management
Tool (CMT).
.
Additionally, disputes can become formal Customer Claims. Definitions of Customer Complaints
and Claims can be found in the Europe document “Handle a customer or BusinessPartner Claim”
which is available on WorkDirect:
http://d12db054.de.ibm.com/q_dir/qmx/ww/qd7pro.nsf/($ProcNum)/EM-CSM-00041
Upon initiation of the claim and while the Claim Process is ongoing, the dispute must remain
opened and assigned to the current DRO. Only once the claim has been fully approved, the DRO
will handle manual credit note creation of approved claim amount (as stated in the Settlement
Letter). As claim process is often longer than simple dispute resolution, the DRO should provide
CDMS / Engage AR updates on a bi-monthly basis instead of weekly.
2. Process for Dispute Resolution through External Claim Process (Risk of Loss - ROL
process)
Whenever a dispute is being resolved through the External Claim Process (ROL), the dispute
should remain open until its final resolution (ie reimbursement by insurance company). This
dispute should remain assigned to the adequate DRO (Business as Usual) and stay under his
responsibility until final resolution of this claim. The DRO should update the dispute in CDMS on regular
basis
For more details, Out of Policy Claim Community:

https://w3-
connections.ibm.com/communities/service/html/communitystart?communityUuid=f71fa119-ef7b-
41d2-87dd-f892120a674e
5.3.2.5.2.15. System Support

The Dispute Management Process is supported by the Common Debt Management System
(CDMS) and Engage where deployed.
5.3.3.5.2.16. Roles & Responsibilities

Disputes will normally surface from Direct Customer calling activity or from an Arrears Letter.
However Disputes can be identified by anyone in IBM who has regular contact with the
Customer.
The following steps (reference to each section included in the below flowchart), listed below by
Dispute Role, exist in the Dispute Management Process:
1. Registering a dispute - Dispute Initiator (CDMS only)usually CSOL, B2B or IGF COF
Collection teams)
Before registering a dispute it is imperative to understand the exact nature of the query raised by
the Customer. Is the AR item disputed because it does not match the contract or do the goods /
services delivered not meet to the standard expected by the Customer?
The Dispute Initiator is responsible for registering received dispute information from any source
in CDMS (when no other system is used) immediately and submitting it for assignment to the
responsible AR Collector in his role as Dispute Manager. It is crucial that the dispute is passed to
the AR Collector with a minimum delay in order to reduce the impact on debt collection and to
meet the client’s expectation with regards to a fast resolution of the issue.
The minimum details required for registration of any dispute are:
o Name and title / department of the person who is disputing the AR item(s)
o Customer contact telephone number (when available)
o Customer contact e-mail address
o Complete and concise details on the reason for the dispute (as provided by the customer):
1. What does the customer not understand or what does he disagree with?
2. What item line on the invoice is being disputed (if not the entire invoice) and why
(disagreement on price, quantity etc.)?
3. What is the customer expecting as a resolution?

o Where applicable:
1. Has the customer already spoken to someone in IBM regarding this issue? If so, to
whom and when?
2. Who else in the client company is involved? Obtain the name of the person who may
have rejected the invoice or credit note (purchase department, approver etc.)
3. Details of any additional documentation required
4. List of any other AR items impacted by the same dispute reason
These minimum details must be sufficient to prevent on the one hand that the AR Collector
would need to call the customer before the dispute can be assigned timely to the appropriate
DRO, and on the other hand the DRO to start working on it before calling the customer.
Understanding the exact nature of a dispute as well as the above required information is needed
to ensure the correct and immediate identification of the DRO and Dispute Reason Code for
each dispute. Details on these Reason Codes will be included in Appendix A. The responsible
DRO and the escalation path can also be entered by the Dispute Initiator during Registration.
Selecting the names for these fields is however optional and can also be left blank for the
Dispute Manager to fill in. Further clarifications on dispute assignment will be included in
subchapter 2.2 below.
2. Assigning and Opening a dispute - Dispute Manager (AR Collector)
2.1 Assigning a previously Registered dispute (CDMS countries only)see step 1

for details on Registration)
Upon receipt of a Registered dispute, it is the AR Dispute Manager’s responsibility to verify that
the:
• details provided in the dispute in CDMS are sufficient (see minimum requirements above)
• dispute reason provided by the customer is a valid reason for dispute (see dispute
definition in chapter 5.2.1)
In case one or both of the above conditions are not met, the Dispute Manager will need to refuse
the dispute in CDMS, including clarifications on the reason for Refusal.
In case both conditions are met, the Dispute Manager has the responsibility to identify the correct
Dispute Resolution Owner.
2.2. Opening a new dispute
The Dispute Manager has the following responsibilities:
• Ensuring all disputes are raised with the required detail to allow the DRO to immediately
proceed with the Dispute Resolution activities. Minimum details required for opening any
dispute are:
o Name and title / department of the person who is disputing the AR item(s)
o Customer contact telephone number (when available)
o Customer contact e-mail address

o Complete and concise details on the reason for the dispute (as provided by the customer):
1. What does the customer not understand or what does he disagree with?
2. What item line on the invoice is being disputed (if not the entire invoice) and why
(disagreement on price, quantity etc.)?
3. What is the customer expecting as a resolution?
o Where applicable:
1. Has the customer already spoken to someone in IBM regarding this issue? If so, to
whom and when?
2. Who else in the client company is involved? Obtain the name of the person who may have
rejected the invoice or credit note (purchase department, approver etc.)
3. Details of any additional documentation required
4. List of any other AR items impacted by the same dispute reason
• All available information on the dispute should be logged in CDMS or Engage AR) by the
Dispute Manager.
• Identify the resolution area and select the appropriate DRO In case that the Dispute Manager
assigns the dispute to the incorrect DRO, the DRO to whom the dispute is assigned, should
reject the dispute in CDMS and add a comment with the name of the correct DRO.
Note: Identification of the correct Dispute Resolution Owner is one of the key criteria for timely
resolution. In case the dispute is caused by an IBM invoicing error (i.e. IBM has not billed
according to the contract), the Dispute Resolution Owner will be within the Q2C organization.
If however the dispute is related to goods / services provided not meeting the standard
expected by the Customer, or if the price or terms do not match an agreement made outside
of the contract or other contractual issue, the Dispute Resolution Owner will be the responsible
Sales or Service representative for that customer.
Note 2: As per agreement reached in August 2013, management of Dispute resolution is

delegated from GBS Business teams to Q2C Services (Europe IOT only).
Note 3: As per agreement reached in May 2014, management of Dispute resolution is

delegated from GTS Business teams to Q2C Services (Europe IOT only).
Note 4: for MEA, as per agreement reached in May 2016 for GBS and IS (only South Africa,
CWA – Central West Africa and EAF – East Africa) and for TSS (for all countries),
management of Dispute resolution is delegated for Business teams to Q2C Services.
As per these agreements, the coordination and management of Dispute resolution is

delegated from Business teams to Q2C Services. Q2C Execution have taken over the co-
ordination and management of all new disputes but there will still be circumstances where
input and/or action from Brands (Business units) is required to reach final resolution of a
dispute.
• Where applicable, re-assigning the dispute to the correct DRO without delay (based on the
details given by the DRO to whom the dispute was previously assigned).
• Regular monitoring of all Open Disputes and their status.
3. Managing and Resolving a dispute - DRO

It must be kept in mind that how you will deal with a dispute is of vital importance to how the
customer will perceive IBM. This experience might have an impact on his decision making in the
future.
Once a dispute is assigned by the AR Dispute Manager to a DRO, the Dispute is passed
automatically by the system to the identified DRO. An e-mail notification is sent and will advise
the DRO that he/she has been identified as responsible person to resolve the dispute and that
his/her action is required.
The DRO has the following responsibilities:
• Accept or Reject the ownership of the Dispute Resolution by immediate system update. In 2
specific scenarios the DRO is entitled to reject the dispute. In all other scenarios the dispute
should be accepted by the DRO.
o Incorrect DRO: the DRO should immediately advise the Dispute-Manager if he/ she
believes that he/ she is not the correct DRO and who the correct DRO should be
o Missing mandatory dispute details: complete list of this mandatory information can be
found in sub-chapters 1. Registering a dispute and 2.2. Opening a new dispute.
Failure to respond promptly to a new Dispute notification will cause the system to assume
acceptance and to start the automatic escalation process (more details on this escalation process
are included below). It is therefore recommended that the DRO accepts or rejects the dispute
immediately upon receipt.
• For Accepted Disputes, decide what solution is required for prompt resolution.
• Contact your customer without delay and inform the customer that you are the one who will
be handling the resolution of the dispute.
• Discuss the proposed solution with the Customer and update CDMS including the expected
resolution date. Note that in the event the Dispute becomes a formal Customer Claim, any
proposed solution cannot be discussed with the Customer until it has been approved by the
appropriate Claims Approval Board.
• Work with the appropriate functions to execute the solution.
• Regularly keep the Dispute Manager up to date on the progress made on the Dispute
Resolution by adding comments in CDMS / Engage AR. CDMS / Engage AR should be
updated as an absolute minimum once a week. In the event no progress was made, it should
be logged in CDMS / Engage AR accordingly.
• Also keep your customer updated about the progress.
• Once the solution is in place:

o Ensure the Customer accepts that the Dispute is resolved and that there are no other
issues preventing the customer from accepting the AR items and eventually settling these
items.

o Update CDMS / Engage AR with details of how the issue was resolved, including any
credit/re-bill details and confirmation of client agreement that they are satisfied with
resolution and that dispute can be closed.
o Verify the correctness of the Dispute Reason Code (ensuring that the Code used is the
most appropriate to describe the dispute root cause) and request Dispute Manager for re-
coding when necessary.
• Update the Dispute Status in CDMS to Solved (not applicable to Engage AR) (further details
on Solved and Closed Status are included below).
• Dispute resolution may require raising a credit note to adjust or amend the original
invoice(s). In some cases the invoice will need to be credited in full and re-billed. As Raising
Credit Notes requires specific documentation and approval(s), it is part of the DRO’s
responsibility to ensure this is completed and stored according to business as usual country
processes and approval levels.
4. Closing a dispute – Dispute Manager (AR Collector or DRO in case of Engage AR)
Upon notification from the DRO that the dispute has been solved to the client’s satisfaction and
that there is no further reason preventing approval for payment, confirm agreement with client
contact.
Closing the dispute on CDMS (further details on Solved and Closed Status are included below).
In Engage AR the DRO should close the dispute directly himself.
For more information the Global Dispute Management process, visit below box folder. It
includes also the link to the global dispute management process in Engage AR.
https://ibm.box.com/s/w1l2uvbxjkmvxob61cwx3c7d2sykkjm6
https://ibm.box.com/s/qhp3ydb41ho57aovji7yvtgaitbpx3qe
5.3.4.5.2.17. Dispute resolution: definitions of Solved

and Closed Dispute Status
A dispute can be considered Solved(and coded accordingly in CDMS) under the following
conditions:
• Details on the Dispute Resolution have been communicated to the Customer and included
in the CDMS / Engage AR dispute comments.
• This agreement can be either an oral agreement or written agreement. In both scenarios the
agreement and details on the resolution need to be documented in CDMS / Engage AR
comments.
Customer notification of dispute resolution resides with the person who is most suitable to
explain the dispute's resolution (Q2C Execution (DRO or AR), CRR, Client Team, or Line of
Business (LOB).

As most cases will require detailed contractual knowledge, we expect that the DRO will
need to ensure the customer or BP notification is done:
– by the LOB in complex cases or where the Q2C execution team is not allowed to
contact the customer/BP
– by the Q2C Execution team in cases where the LOB is in agreement with
customer/BP contact by themselves
In exceptional simple cases, Trade AR collectors can ensure the dispute resolution
communication while performing the collection call. When moving to ‘solved or closed
status, all the necessary information related to the credit and/or rebill needs to be populated
in CDMS / Engage AR by the DRO to allow the AR collector to make the combined
notification/collection call.
Examples: for credit/rebill due to change of address or VAT, contact information, addition of
PO reference or for complete credit without rebill.
– For IGF COF similar simple cases, the DRO needs to provide the resolution details
to the BP on a negative confirmation basis (see negative confirmation approach
hereafter).
• The DRO has contacted the client and obtained explicit (oral or written) agreement from the
customer on the proposed resolution through Notification Letter Process (instead of the
initially requested correction by credit/rebill). This contact as well as agreement needs to be
logged in CDMS / Engage AR comments once the letter is sent and prior to setting the
dispute to Solved. This will allow AR to also consequently close the dispute in CDMS. For
further details on the Notification Letter Process, see chapter 5.2.6 of this document.
• The customer/BP agrees that the dispute has been resolved to their satisfaction, meaning
that the action plan to resolve the identified issue(s) has (have) been executed and that
he/she is satisfied with this completed resolution. In addition, the client confirmed that there
are no further issues preventing the customer from accepting the related AR items and
eventually settling these items.
• All AR items within a dispute must be resolved before a dispute can be coded as solved in
CDMS (or closed in case of Engage AR). Note that in the event multiple AR items are
included in the same dispute, AR items accepted by the customer can be removed from the
existing dispute. Details on this partial resolution of a dispute need to be logged in CDMS /
Engage AR accordingly.
Note that it is not needed for the customer to confirm that the payment is initiated, in process or
will be made within a specific time frame (for example in next payment run). The requirement to
consider a dispute as Solved (Closed in Engage AR)is the customer confirmation that the
Dispute Reason is solved, that there are no other issues preventing the customer from
accepting the AR items, and that there is no further reason preventing approval for payment.
In exceptional scenarios only, this (oral or written) customer agreement of the Dispute
Resolution is not required. These scenarios are limited to the ones described below:
• Negative confirmation approach (meaning that a unilateral deadline will be communicated

to the customer/ BP):
– in case a customer/BP purposely delays the agreement of the Dispute Resolution
and there is clear evidence that the dispute root cause has been resolved, a negative
confirmation can be sent to the customer/BP. For trade disputes, a minimum of 2

previous communications have been sent to the customer including details on the
resolution. The DRO can agree with the Dispute Manager to send a clear statement
to the customer/BP that from IBM’s standpoint the dispute reason is resolved and the
dispute will be closed after 5 working days in case the customer/BP does not raise
any objection.
Upon completion of the provided timeframe of 5 working days, the dispute status can
be set to Solved.
– in case of COF simple cases only (e.g. complete credit or credit/ rebill), the DRO may
provide the resolution details to the BP on a negative confirmation basis without any
previous communication to the BP. Upon completion of the provided timeframe of 5
working days, the dispute status can be set to Solved.
Note: It is mandatory to include a reference to this timeframe of 5 working days in the negative
confirmation communication to the Customer / Business Partner.
Suggested wording to be used: “We consider you agree with the resolution of this dispute unless you
notify us within the next 5 working days articulating why you do not agree with the stated resolution”.
A dispute can be considered Closed (and coded accordingly in CDMS / Engage AR) under the
following conditions:
• Upon notification from the DRO that the dispute has been set to Solved and after
verification by the Dispute Manager that the applicable conditions for Solved status are
met (as described above), the dispute must be closed. (CDMS only)
• The invoice has been accepted by the customer based on the provided clarifications in
the Notification Letter sent by the DRO. This specific Notification Letter Process will be
described in more detail in chapter 5.2.6.
• In case the Dispute Resolution Process cannot be successfully completed due to

customer’s refusal of the proposed resolution by IBM according to T&C’s of the contract,
write-off of these items may be considered as an alternative solution. The write-off
package will be presented to the AR Squad Lead for initial approval and final approval
must be according to country delegated Powers Reserved (see chapter 5..7.3 on this
document). Approvals must be granted in advance of any discussion with the Customer
to agree resolution and subsequent dispute closure.
Upon Dispute Closure the Dispute Manager needs to specify an appropriate probability of the
AR items being settled by the end of the month and resume the subsequent collection activities.
5.3.5.5.2.18. Automatic Dispute Escalation Process

To ensure timely and efficient dispute resolution it is important to have always the appropriate
escalation paths (level 2 and 3) in place. It is the responsibility of the ones nominated as
escalation points for each dispute to support immediate, efficient and effective Dispute
Resolution and are therefore regularly informed about the dispute aging, the total number and
value of the disputed AR items his/her department is responsible for.

Failure to respond promptly to a new Dispute notification will cause the system to assume
acceptance and to start the automatic Escalation Process. It is therefore recommended that the
DRO accepts or rejects the dispute immediately upon receipt. There is no automatic escalation
process in Engage AR
• Automatic e-mail notifications are sent by CDMS to all 3 levels as defined in the Country
Process and CDMS application where disputes remain open beyond pre-set aging limits, set
for the time taken to resolve a dispute. Three limits can be set, for which the standard values
are 7, 14 and 21 days. Note that the report does not list only the disputes for which the aging
limit has expired, but also all the other disputes assigned to the DROs concerned.
• At regular intervals (as set in the Country Reference Database in CDMS) the system checks
the age of the disputes. If there are any disputes older than any of the aging limits, reports are
generated. A report is sent to the DRO (level 1) if there are any disputes over the first aging
limit, to the DRO level 2 if there are any disputes over the second limit and to the DRO level
3 if there are any disputes over the third limit. There are 3 levels of Dispute summary and
escalation which takes place on an ongoing basis
o 1st level: all open disputes will be summarized in detail to the DRO every 7 days.
o 2nd level: on the10th and 20th day of each month a report is sent to the DRO level 2,
including the details for all open disputes over 14 days owned by the DRO level 1
(usually though not necessarily their reportees).
o 3rd level: On the 10th and 20th day of the month an additional report is sent to the
next level (DRO level 3) listing the details of the open disputes over 21 days of aging.
Further escalation of still unresolved disputes will be done on a selective basis by country AR
management, following joint country Finance / Q2C / EMEA Treasury executive agreement.
5.3.6.5.2.19. Forecasting of invoices in dispute

All invoices in dispute shall be forecasted at 25% to earliest next month, until resolution
confirmation from DRO is received (e.g: credit rebill, customer accept to pay…), or after the
quarter end if there is no outlook during the current quarter.
Once resolution confirmation is received from DRO, then forecast shall be moved to 75%.
5.3.7.5.2.20. Notification Letter Process

At the moment of this process review, the Notification Letter Process is implemented in all
European Major Market countries excluding Switzerland (as per country specific legal limitations)
and used by the Services, Hardware and Software teams.
The Notification Letter Process aims to improve the resolution time for administrative disputes by
sending a notification letter to the customer rather than using the alternative credit and re-bill
solution. B2B customers are automatically excluded from this process due to the necessity of a
credit and re-bill action in all disputed circumstances.
Disputes are considered administrative when a customer is requesting additional clarifications or

missing information about an AR item which is fiscally and legally correct. Reduction of the

resolution time generally will result in positive impact on IBM’s cash flow as well as the client’s
satisfaction, and the Notification Letter Process is therefore considered the preferred solution.
For identified disputes where the customer indicates that the Notification letter may be used as
opposed to a credit and re-bill solution, the Collector will enter this information at the time of
opening the dispute. Similarly, if the customer has requested to be exempt of this process, it is
expected that the information be made available in CDMS / Engage AR dispute comments.
Further information and templates of the letters can be found in the following QMX document:
https://d01db034.pok.ibm.com/q_dir/qmx/aca/qm8pl.nsf/procnum/STS-O-1050?OpenDocument&Login
5.3.8.5.2.21. Specific Dispute situations
1. Disputes related to Customer’s Purchase Orders:
Not applicable for Engage AR

The Purchase Order (PO) disputes must be coded depending on their root causes with one of the
8 PO Dispute Reason Codes (see table below). By using the PO Reason Codes no further PO
Local Codes are necessary - except Local Codes C1/C2 to indicate 'Commercial Financing' (if
appropriate).
Reason Short Name Description

code
P1 No PO - New PO Client Invoice raised without a PO because the Client is not listed as PO Driven
on the Global PO Tool for the goods or services billed.
Additional required action: Client must be added to the Global PO
Database
P2 No PO - Existing PO Client Invoice raised without a PO even though the Client is already listed as
PO Driven on the Global PO Tool for the goods or services billed
P3 Wrong PO on Invoice The PO reference stated on the invoice does not relate to the goods or
services billed
P4 Date expired on PO/PO Waiver The date of the PO or PO Waiver has expired and renewal of the PO is
not currently in progress
P5 PO Gap - Renewal in progress The date of the PO or PO Waiver has expired and renewal of the PO is
in progress
P6 PO Value Overspent The total/cumulative amount billed against the PO has exceeded the
current PO value
P7 No PO but PO Waiver in place Invoice raised without a PO but only because a PO Waiver was in place
at the time
Additional required action: Confirm whether - and if applicable add - the
Client to the PO Waiver Blacklist as described in the Global PO
Guidance documentation.
P8 PO Issue but no suitable code This code must only be used when none of the above codes accurately
describe the Client's PO Dispute.
Important: Specific reason needs to be added in the Dispute Closing
comment

Note that also here it is key to have correct Dispute Reason Code for each dispute. Whilst the
Dispute Manager must select a dispute code in CDMS at the point the dispute is identified, further
investigation of the issue by the DRO may identify that the actual cause of the dispute is different
and another dispute reason code may be more appropriate. It is the DROs responsibility to verify
the correctness of the reason code and request re-coding when necessary.
Additional process documentation on the Global PO process can be found in the Global PO tool
under the help section: https://cfsrvk.rochny.ibm.com/GlobalPO/main.jsp.
The PO process documentation involving AR are the following:
1. PO Dispute Management using Global PO Tool for AR (describing how to assign the most
suitable PO Dispute reason code).
https://d01db034.pok.ibm.com/q_dir/qmx/aca/qm8pl.nsf/procnum/CF-P-2591?OpenDocument
2. PO Waiver and Blacklist Management using Global PO Tool (describing the AR

involvement in “black listing” a customer not respecting the signed PO waiver
agreement):https://d01db034.pok.ibm.com/q_dir/qmx/aca/qm8pl.nsf/procnum/CF-P-
2582?OpenDocument
2. Disputes that become Suspense situations:
Where Customer Accounts or Invoices are formally accepted by IBM Legal function as their
responsibility, and they have be to be flagged accordingly in CARS / CDMS / Engage AR. See
also section 5.4 on Pre-Legal Activities of this document.
Any Disputed AR item, transferred to Legal in line with the Accounting Procedure AR (APAR)
requirements, and when the customer as a whole is not Legal though only some of the items are,
has to be handled as follows:
• Use Action Code “Legal” (Referred to Legal) in CDMS / Engage AR to identify the
concerned AR item(s). This Action Code will allow tracking of all individual AR items
assigned to legal.
• Ensure no automatic arrears letters are sent, and no LPF invoice is produced, regarding
those items.
3. Disputes that become a Concession
A "concession" is a deviation to an approved contract price or its terms and conditions. A

concession can take different forms, including an agreement to reduce future charges for
existing services or to issue credits for services already, or not yet, rendered. For additional
information, please refer to AP09 and INT 04-02
There are several situations which could give rise to a concession, i.e.:
• A deviation to an approved contract price or its terms and conditions where IBM
concedes on either not billing, providing credit or free service.
• Resolution of an issue or potential issue or used in the interest of preserving future
business relationships.
• IBM concedes elements of contracted Revenue/GP which is given away during a
Renegotiation and/or "Give to Get" scenario where IBM gets something back in return -
i.e. as additional years contracted service in return for reduced price/scope in the
current contract.

Concessions are managed by the business through a different tool than CDMS / Engage AR.
Such cases are considered as business disputes and during this period, collection activities are
discontinued and arrear letters stopped.
The DRO is responsible to follow-up with the business to ensure the concession is on-going and
should update CDMS / Engage AR twice a month.
If the concession is finally rejected and the business confirms the invoice is due, then AR will
close the dispute and restart collection activities.
5.3.9.5.2.22. Globel Dispute Metrics
Metric Corporate Description Calculation logic Owner

The amount of time it
takes to from the total # of days between
Total Cycle Time : Global creation date to the time a dispute was
DRO
Days to Resolve (Accelerated Metrics) the date that the created to the closing
dispute is being of the dispute
closed
Calculate the # of days
The amount of
taken from the time
time between a
stamp
Days to ID Local Indicator dispute creation date AR
of the invoice to the
and the original
date when dispute was
invoice date
created
Percentage of aged
Divide total disputes
disputes (030) versus
>30 days compared
Aged Disputes: >30 Local Indicator the total volume of DRO
total # of
open dispute
disputes open on file
Note: Assumption is that Q2C Professionals own the Root Cause and Preventive Action
Analysis. AR Professionals / Squads own AR Days to ID and Preventative Identification
Analysis.
AR Management must be able to demonstrate that communication with customers and DROs
has commenced, reminder and escalation activities are taking place and that Aged Disputes
and Trends are subject to review by management.
5.4.5.3. Cash Administration

Procedures include:
• Cash Application
• Unapplied Cash
• Alternative Payment Methods
• Cash Control
• Direct Debits
• Multi-Company
• A/R Accounting

5.4.1.5.3.1. Cash Application

Sub-Process Description
Cash application encompasses the daily activity of application of the cash received from IBM’s
bank accounts against open invoices and credit notes in CARS which converts Open items to
Settled items.
Linkage
• With Treasury Operations for the banking relationship / bank statement receipt.
• With Treasury Accounting for identification of customer receipts.
• With A/R Accounting for reconciliation purposes.
• With the AR Collectors for query handling.
In the following process description for Cash Application, the liaison with the customer is
described as being in the hands of the AR Collectors who are responsible for the overall customer
account.
However, on an exceptional basis and for dedicated customer accounts the country AR
Management in conjunction with the responsible Squad Leader may opt to let cash administrators
also contact the dedicated customers directly. If this is the chosen option for the country, this must
be documented and shared with the Europe & MEA AR Process Lead for information purposes
only. Since 2018 people in Madrid center can have a mixed role that include cash administration
and collection tasks. The usage of this combined role is a squad based decision.
Steps
On a high level, the steps can be summarized as follows:
1. Receive daily bank statement details from Treasury Operations/ the bank including cash
received and associated remittance advices and the correlating accounting booking from
Bank Accounting.
2. Allocate payments correctly using Customer remittance advices. Cash application should
take place within 1 business day of cash receipt. Any exception to this rule has to be
identified and followed up until resolution as per control point SOX KCO 521.
3. Resolve and monitor all unapplied cash.
Common practice for cash allocation :
1) cash apply is to be performed according to customer's instruction. i.e. If a customer specifies a

payment is for a certain invoice, the payment must be allocated in line with customer request.

2) In the event the customer does not provide clear instructions, the payment remains unallocated and
collection attempts to contact (via email or phone) the client in order to get payment allocation details.
3)If the customer can not be reached and there is no doubt on how to allocate (there is only 1 invoice left
for the same amount, the totals of several invoices match the payment,…) then the collector can allocate
and inform the customer how the payment was allocated.
4) In case the customer cannot be reached via email or does not answer the phone, the payment can be
applied to the most suitable AR item versus the payment after informing the client (with email negative
confirmation) in order to ensure customer and IBM has same view. Negative confirmation should only be
used as a last option and only after investigating all other options within IBM and with the customer to get
a confirmation on the proper allocation details.
Note : GEO/Market specifics around negative confirmations and cash application should be taken into
account.
Annotation: Now is in place the Cash Application Tool (CAT), which supports an automatic/ semi-
automatic cash application process, however, the scenarios outlined hereafter should still apply.
Cash Administration Subprocess Cash Application
Receive Payment
Does payment match

Yes remittance No
information?
Allocate payment Verify which of the

according below Scenarios
remittance advise applies and follow
Inadequate Payment of
Twice Multi
information Overpayment C/N settled
Payment Currency
provided invoices
Payment of Proforma
Partial- / Incorrect
written-off invoices &
Underpayment Payee
invoices Prepayment
If the payment matches exactly the remittance information, the payment has to be applied
accordingly and the related Open items in CARS will be converted to Settled items.
However, in all other cases, where such a simple execution is not possible, one or more of the
mentioned scenarios described hereafter will need to be applied.
Withholding tax deduction scenario:

Withholding tax, also called retention tax, is a government requirement for the payer of an item
of income to withhold or deduct tax from the payment, and pay that tax to the government.
Withholding Taxes may be identified when customers initiate a payment to IBM.
Customers send remittances advices highlighting the amount withheld on specific invoice(s).
Together with the remittance advice, a WHT Tax certificate is sent in order to justify the
remaining unpaid amount. This certificate will be used by the Cash Administration team as
evidence to perform a General Ledger adjustment to fully clear the invoice(s) in CARS and send
the unpaid amount to Accountancy.
In many cases, there is a time delay in receiving the customer’s WHT Certificate. In the
Allocation Process, the Cash Administration team allocates the customer's payment as per the
information received in the remittance. If a part of the invoice(s) is withholding tax, the
outstanding amount will remain in CARS for the collector to follow the Collection Process by
requesting the missing certificate that allows for settlement of the remaining tax portion.
In case the WHT Certificate is not received at the same time as the payment, the open AR is
flagged with status code C in CARS by the Cash Administration team at the moment of payment
allocation.
Collection may detect other WHT cases not identified in the allocation stage and in such
instances, the collection team may flag the corresponding invoice with status code C.
Global CF QMX:
Withholding tax process:
https://d01db034.pok.ibm.com/q_dir/qmx/aca/qm8pl.nsf/procnum/CF-O-0909?OpenDocument
Cash Application - Scenarios
A. Inadequate information provided to apply cash

1. If the customer is not identifiable

a. The complete payment has to be maintained in CAT tool as an open payment. For manual
payments (payments not supported by the CAT tool), the payment will be put as
unallocated on an “unknown customer” dummy account.
Note: Before month-end any open payment in CAT has to be clarified as AR payment (and be
allocated in CARS) or as non AR payment (and closed in that way in CAT)
b. Investigation actions, involving e.g. Treasury Operations or directly the related bank shall
be initiated in order to find out the correct customer
c. Once the customer and the related customer account in CARS have been clearly
identified, the payment is to be applied from CAT/moved to the correct account utilizing a
Move-Adjustment in CARS in order to allow subsequent allocation.
If the payment is identified as a “Non-AR” payment it will be transferred from CAT to that
category or removed from CARS using the correspondent General Ledger adjustment
2. If the customer is identifiable

a. The payment values should be checked across any other associated Customer/
Enterprise accounts the payer might have within IBM.
b. If the check is positive, the payments are to be allocated according the investigated
matching invoices and the Collector should be notified of the performed allocation in
order to pass this information to the customer
c. If the check is negative, the payments have to be put as unallocated cash on the
customer account and the responsible collector should be notified in order to get in touch
with the customer for provision of sufficient remittance details


B. Partial- / Underpayment
Scenario: Partial- / Underpayment
Cash
Application
Identify Potential
Partial- /
Underpayment
situation
Explanation given
Yes No
why lower amount?
Correct invoice
Netting requested? No
Yes reference given?
No
Yes
Put partial
Is complete Allocate partial payment as
remittance advice Indicated item given as payment unallocated on the
given, including the reason for deduction on according customer account
deducted AP item? customer account? remittance advise
Yes Yes
No
No
Refer to Item still Notify Collector
Put underpayment Corporate Netting unapplied? accordingly
as unallocated on Policy for Yes
the customer assuring that all
account relevant
agreements/
approvals are Allocate
obtained before underpayment Is complete
and items to remittance advice Collection
proceeding Process
Notify Collector be considered given for all items?
Yes
accordingly according
remittance
No
advice
Ask Collector for
All approvals confirmation that
obtained? No referred C/N is
Collection about to be issued
Process
Yes
No No Confirmed?
Yes
Allocate against
identified items, Put underpayment
using the as unallocated on
underpayment to the customer
leave the balance account Allocate
on the less aged underpayment
item(s) according
remittance advise
Notify Collector
accordingly
Wait for
Use ‚payment in’
confirmation from
processed by
Collector that C/N
involved Treasury
Collection is on account and
function to apply
Process can be applied
to the outstanding
balance

1. Identify a potential Partial- or Underpayment situation based on actual payment

from the customer and the given remittance information
2. If within the remittance advice the customer did not indicate why the payment is
lower than the amount of the invoice(s)
a. If a correct invoice reference is provided by the customer
i. Allocate the partial payment to the open item according the
remittance advice
ii. Inform the responsible Collector accordingly to clarify the situation
with regards to the remaining outstanding amount with the
customer
b. If a correct invoice reference is not provided by the customer
iii. Put the partial payment as unallocated cash (UAC) on the
customer account
iv. Inform the responsible Collector to clarify the situation with the
customer
3. If within the remittance advice the customer did indicate why the payment is
lower than the amount of the invoice(s)
c. If the customer is not referring to perform a netting transaction with an
Accounts Payable item
v. If the customer has indicated any item, such as a Credit Note or
any other payment made beforehand
1. If the indicated item is still unapplied on the customer
account
a. Allocate the underpayment and the indicated item to
the referenced invoice as per remittance advice
2. If the indicated item is not unapplied on the customer
account
a. Put the underpayment as unallocated cash on the
customer account
b. Inform the responsible Collector to clarify the
situation with the customer
vi. If the customer has not indicated any item, such as a Credit Note
or any other payment made before
1. If the customer has provided a complete remittance advice
considering all items to be included
a. Ask the responsible Collector for confirmation that the
referenced Credit Note is about to be issued
i. If the Collector does confirm that the credit
note is about to be issued
1. Allocate the underpayment according
the given remittance advice, leaving a
balance
2. Upon confirmation from the Collector
that the Credit Note has been received
on the customer account, allocate to the
left balance

ii. If the Collector does not confirm that the credit

note is about to be issued
1. Put the underpayment as unallocated
cash on the customer account
2. Inform the responsible Collector to
clarify the situation with the customer
2. If the customer has not provided a complete remittance
advice considering all items to be included
customer account
d. If the customer is referring to perform a netting transaction with an
Accounts Payable item
vii. If the customer has provided a complete remittance advice,
including the Accounts payable item(s) to be considered
1. To contact with the correspondent EMEA Treasury for advice and
guidance on Netting for assuring that all relevant agreements and
approvals are obtained before proceeding with the next steps
2. If the necessary approvals have been provided accordingly
a. Allocate the underpayment against the referenced
item(s) according the remittance advice following the
principle to leave the balance on the less aged
item(s)
b. Use “payment-in” processed by the involved Treasury
function to allocate to the outstanding balance
3. If the necessary approvals have not been provided
accordingly
customer account
viii. If the customer has not provided a complete remittance advice,
including the Accounts payable item(s) to be considered
1. Put the underpayment as unallocated cash on the customer
account
2. Inform the responsible Collector to clarify the situation with
the customer


C. Double Payment

Scenario: Apparent Double Payment
Cash
Application
Identify apparent
double payment
Check against
recurring invoicing
activity (incorrect
reference on
remittance advice)
Unique open item

Yes No
identifiable?
Apply payment to
Put Payment as
identified unique
unallocated on the
recurring open
customer account
item
Notify Collector to
Notify Collector to
inform the
clarify the situation
customer about
with the customer
taken actions
1. Identify an apparent Double Payment

2. Check against any recurring invoicing activity on the customer account in order to
identify if a wrong invoice reference has been provided on the remittance advice
3. If a unique open item can be identified on the customer account
a. Allocate the payment to the identified unique open invoice
b. Notify the Collector to get in touch with the customer in order to inform
about the taken actions
4. If a unique open item can not be identified on the customer account
a. Put the payment as unallocated cash on the customer account
b. Notify the Collector to clarify the situation with the customer in order to get
correct remittance information

D. Proforma Invoices and Prepayments

Scenario: Proforma Invoices and Prepayments
Cash
Application Please Note:
Proforma invoices are not
permitted legally in most
countries
Identify that Proforma invoices do not
payment is meant appear on CARS
for a proforma
invoice or as a
prepayment
Put payment as
unallocated cash
on customer
account
Inform the
Collector and ask
for information
once final invoice
is raised
Upon information
from the collector,
allocate the
money to the
correct invoice
No Balance left? Yes
Notify Collector
accordingly (no
N/A
matter if balance
positive or
negative) to clarify
situation with the
customer
1. Identify a payment that is either related to a proforma invoice or which is a

prepayment, means related to an invoice which is still about to be issued
2. Put payment as unallocated cash on the customer account
The common pre-payment flag is “J” status (CARS IW field FCUCPRE changes from
‘N’ to 'Y’).
Pre-payment flag should be documented by the AR Cash Administrator as it would
exclude this payment from the Unallocated Cash measurements.
3. Inform the responsible Collector about the prepayment and ask for confirmation
once the final invoice is issued and on the customer account

4. Upon information from the Collector, allocate the unallocated cash to the related
invoice
5. If the application of the cash does not leave any balance
a. No further steps needed
6. If the application of the cash does leave a balance, regardless if this balance is
positive or negative
a. Inform the responsible Collector to clarify the situation with the customer
For further Pre-payment guidance including criteria for flagging in CARS, the following
document should be consulted:
Global CF Library
Prepayments DLP (STS-O-2229)
E. Overpayments

Scenario: Overpayment
Cash
Application
Identify
Overpayment
Situation
Does remittance
Yes advice allow to No
allocate partially?
Allocate payment
(partially) Put payment as
according unallocated cash
remittance advice on the customer
account
Put left
overpayment
amount as
unallocated cash
on the customer
account
Inform collector for

necessary
clarification with
the customer

1. Identify an overpayment situation

2. If the remittance advice allows to allocate partially
a. Allocate the possible partial part of the payment according the remittance
advice
b. Put the left overpayment amount as unallocated cash on the customer
account
c. Inform the responsible Collector about the necessary clarification with the
customer
3. If the remittance advice does not allow to allocate partially
b. Inform the responsible Collector about the necessary clarification with the
customer
F. Incorrect Payee

Scenario: Incorrect Payee
Cash
Application
Identify incorrect
payee
Is the correct payee

an IBM owned No
Yes subsidiary?
Is another special
relationship between IBM
Yes and the correct payee
(e.g. divestment like
InfoPrint) existing? No
Is a written/ contractual
agreement for forwarding
Yes No
money in such cases
existing?
Initiate wire
Initiate transfer of transfer to correct Initiate refund
the payment to payee involving Process
correct subsidiary Treasury
Inform Collector Inform Collector

for customer for customer Refund
information/ information/ Process
education education

1. Identify that the customer has made a payment with the incorrect payee (this
could be directly visible to the Cash Administrator or upon information from the
Collector after a customer contact)
2. If the correct payee is an IBM owned subsidiary
a. Initiate the transfer of the payment to the correct subsidiary
i. Preferred Scenario with less cost for IBM:
1. To use an cross-ledger apply/movement adjustment in
CARS
2. If first option is not available: to perform a Call Account
movement (if that possibility is available between the 2 IBM
companies)
ii. Only if Scenario i. is not possible to be followed as more cost for
IBM are created:
1. Check the Global Bank DB following Corporate Instruction
FIN184: https://w3-
03.ibm.com/ibm/documents/corpdocweb.nsf/ContentDocsBy
Title/Corporate+Instruction+FIN+184
2. The Cash Administrator initiates a wire transfer of the money
to the correct IBM subsidiary bank account involving
Treasury Operations and local Treasury systems
accordingly. That Cash Transfer will be documented through
a Refund request for misdirected payments on the
Adjustment Approval Tool AAT
b. The Cash Administrator informs the account Collector to allow him/her to
inform the customer about the actions taken and at the same time asks for
payment to the correct bank account in the future
3. If the correct payee is not an IBM owned subsidiary
a. If there is any ‘special relationship’ between IBM and the correct payee
(e.g. past divestments such as Lenovo, InfoPrint or Dassault).
i. If there is a written/ contractual agreement for forwarding money in
such circumstances
1. The Cash Administrator initiates a wire transfer of the money
to the correct IBM subsidiary bank account involving
Treasury Operations and local Treasury systems
accordingly. This cash transfer will be documented through a
refund request package for misdirected payments through
the Adjustment Approval Tool.
2. The Cash Administrator informs the customer about the
actions taken and at the same time asks for payment to the
correct bank account in the future through a standard letter
to be send to the customer. In parallel the Cash
Administrator informs the Collector in order further
“education” actions can be considered in future collection
calls, in order to prevent the situation to reoccur
ii. If there is no written/ contractual agreement for forwarding money
in such circumstances

1. Initiate the Refund process for disbursement of the money to

the payer
b. If there is no ‘special relationship’ between IBM and the correct payee
(e.g. divestments such as InfoPrint)
i. Initiate the Refund process for disbursement of the money to the
payer
Further Guidelines
1. Only cross-ledger payment/invoice allocation within the CARS system is allowed.

Cross-ledger credit note/invoice allocations are only allowed in countries where taxes
has confirmed this possibility.
2. Detailed records must be maintained of cross-company allocation
3. Credits in favor of one company cannot be used to settle invoices billed to another
company, unless specifically authorized by the customer, and the IBM companies
involved.
Global CF QMX:
Multi-Company Cash Management DLP (STS-D-2076)):
G. Payment of Written-Off invoices


Scenario: Payment of previously written-off invoices
Cash
Application
Identify that
referenced invoice
has been written-
off previously
Put payment as
unallocated cash
on customer
account
Initiate a Write-Off
Reversal
Adjustment
Upon correct
processing of the
Write-Off Reversal
Adjustment,
allocate the
unallocated cash
to the reinstated
invoice
Inform the
responsible
collector
1. Identify that the referenced invoice has been written off previously
2. Put the payment as unallocated cash on the customer account
3. Initiate a write-off reversal Adjustment in CARS, providing the received
remittance information and evidence from CARS showing the previously
performed write-off of the invoice
4. Upon correct processing of the write-off reversal adjustment which has reinstated
the invoice on CARS, allocate the unallocated cash to the open invoice
5. Inform the responsible Collector of the actions taken
H. Payment of Previously Settled invoices and credit notes


Scenario: Payment of invoices that have previously been settled by
Credit Note
Cash
Application
Identify that
referenced invoice
had been settled
with a credit note
previously
Process an
Unapply
Adjustment to the
Credit Note to
reinstate the
invoice
Allocate the
received money to
the reinstated
invoice
Inform the
Collector and ask
for informing the
customer and for
discussing the
actions to be
taken with the
Credit Note
1. Identify that the referenced invoice (within customer remittance information) has
already been settled by a Credit Note previously
2. Process an Unapply Adjustment to the previously allocated Credit Note in order
to reinstate the invoice and the Credit Note on the customer account
3. Allocate the received money to settle the invoice with the payment
4. Inform the responsible Collector of the actions taken for getting in touch with the
customer in order to inform about the actions taken and to discuss the steps to
be taken with the reinstated Credit Note
I. Multi-Currency


Scenario: Multi Currency
Cash
Application
Identify a Multi
Currency Scenario
Can any partial- /

No underpayment Yes
situation be excepted?
Put payment as
unallocated on the Is the received
customer account payment in the same
Yes No
currency as the
invoice(s)?
Put payment as
Apply payment to
unallocated on the
Notify collector for open item(s)
customer account
clarification with
the customer
Is a balance left
Utilize CARS
Yes (positive or No
„CX“-Adjustment
negative)?
to apply to the
open item and
Utilize G/L- initiate exchange
Adjustment for gain/ loss
N/A
booking exchange Adjustment to the
gain/ loss ledger
1. Identify a Multi Currency Scenario – this is to be done by either identifying a

different currency comparing the payment with the invoice currency, or, even if
the currencies are matching the original payment might have been made in a
different currency and was exchanged already by the bank at the day’s rate
2. If a partial- / underpayment situation cannot be excepted
b. Notify the Collector for clarification with the customer
3. If a partial- / underpayment situation can be excepted
a. If the received payment in CARS is in the same currency as the invoice
i. Apply the payment according remittance purposes
ii. If no balance is left
1. No actions required
iii. If a balance is left
1. Utilize a CARS G/L-Adjustment by using the correct
shortcode in order to book the exchange rate fluctuations on
the correct account for exchange gains & losses in the
general ledger

b. If the received payment is not in the same currency as the invoice

i. Put the payment as unallocated cash on the customer account
ii. Utilize a CARS “CX” Adjustment to apply the payment to the open
item and at the same time initiate the correct G/L-booking for
recording the exchange gain or loss
J. Payment Reversal
Any alteration or adjustment to a previously applied payment must only be made with
written authority from the Customer. This includes written notification from the Collector
which is referring to verbal customer contact.
If the request is solely based on internal demands, the requestor must document why the
Customer is not involved, and ask a Squad Lead for authorization.
Responsibilities
All Cash Application activities in the Allocation moment are under the responsibility of the
AR Cash Administrator.
Cash Application of unapplied cash items (UACs) are under the responsibility of the AR
Collector.
Measurements
Unallocated Cash must be regularly reviewed and monitored. (see section 5.3.2)
Turn Around Time for cash allocation from the time the cash is received in CARS.
Controls
Records must be kept of all non-standard application activity (i.e. any application which
does not match the written information provided by the Customer with his payment).
5.4.2.5.3.2. Unallocated Cash Management

Description
Any cash unallocated to specific AR items on a customer number account.
Linkage

With the AR Collection and Cash Allocation procedures.
Steps
• Unallocated cash must be regularly reviewed.

• In case of unallocated items the responsible AR Collector should be contacted.
Contacting customers by telephone and trying to resolve a situation of Unallocated Cash,
is the responsibility of AR Collectors.
Any different set-up of the described roles & responsibilities with regards to the preferred
country A/R contact strategy, have to be clearly set and documented by country process
owners, as outlined under 5.3.1.
• The AR Cash Administrator will inform the AR Collector immediately about any
unallocated payment generated in the Cash Allocation process and provide all data
received from any Treasury sources for those payments.
Note: When possible this information is directly linked in CDMS / Engage AR through a link to the
Unapplied Cash record in Cash Allocation Tool (CAT).
• Actions taken by Collector (Contacting the Customers) have to be documented in CDMS
/ Engage AR in order to track an unallocated payment´s status.
In case that the collector would exhaust the contact attempts with the customer to clarify an
unapplied cash item (UAC), a Write Off will be requested (no Cash on Delivery/Black List flagging
is required for this write off request):
At least 2 contact attempts should take place with at minimum of 5 days between them. These
actions have to be complemented with a final dunning letter to be sent to the customer asking for
bank details for a refund. This letter should also explain that in case of no reply from the
customer´s side within 10 days, the payment record will be written off. Acknowledgment of receipt
will be used if it is a country standard practice.
Note: A template of this dunning letter can be found in the Common Process Appendix document
For UACs with amount higher than 1,5K$, on top of the dunning letter, a parallel communication
to the Account’s Sales or Client Rep responsible is needed. The aim of the communication is to
explain the situation and to provide 10 days for his/her support on clarifying the case.
For UACs above 5K $ the Account’s Collector needs to agree with his/her squad lead an specific
action plan in which the minimum of actions to be done before the request of a Write Off will be
confirmed. This action plan needs to cover the minimum requirements described above.
An UAC write off follows the standard Write Off process explained in section. Therefore the Write
Off approvers will analyse the request and might require any additional action to complement
these minimum requirements.
Responsibilities
Unallocated cash control is the responsibility of the AR Cash Administrator and AR Collector
(shared targets).
Measurements

The Cash Administrator and Collector (shared target) should maintain Unallocated Cash items in
line with the assigned target and address actions when this is not achieved (>30/90/180 days).
5.4.3.5.3.3. Alternative Payment Methods

Description
Payment of IBM invoices can be made by any of the following methods:
- Cheque
- Direct Debit (see section 5.3.8)
- Procurement or Credit Card (as per the Europe DOU with IBM Payment Systems)
- Electronic Payments/Bank Transfers
- Telegraphic Transfers
- Promissory Note
5.3.3.1 Cheque
Cheques can be treated as Cash and used for application unless they are post-dated. In countries
where Post-dated cheques are legally allowable, they should always be returned to the Customer
unless they are subject to prior agreement, in which case settlement is only allowed at maturity
date. Any foreign currency (non local-currency) cheques must be referred to Treasury for
exchange at the current day’s rate, before application.
Cash Accounting Instructions:

https://w3-connections.ibm.com/wikis/home?lang=en-
us#!/wiki/W64d0f8a882a7_40dc_adce_759fa3c0fc32/page/AI-
CASH%20001%20Cash%20Accounting%20Instruction
5.3.3.2 Direct Debit
See section 5.3.5.
5.3.3.3 Credit Card
A strategic Credit Card Model is applied to the following types of Business / CARS invoices:
PCD low end user
Large HW/SW contracts (PCOA/PCFA)
Strategic Outsourcing (CFTS only)
Bluemix/softlayer invoices
Countries where Credit Card payment system is available are listed in the European DOU
between Q2C and IBM Payment Gateway.

Other tactical initiatives, at country level, that cannot provide to CARS the two key Elements: “PS
reference number” and “Payment method” flag will not be part of this solution.
There is an ongoing project to implement credit card solution for Greece and MEA countries for
Softlayer invoices (Egypt, Saudi Arabia, Turkey, UAE).
Further to the above, there is a pilot ongoing in UK that allows the customer the possibility of
making payment for open invoices by credit card.
It is currently enabled for UK only (ledger 10)
Sound business judgment must be used to decide whether to accept a credit card (size of
transaction, creditworthiness of customer, how important it is to the customer, etc…)
Credit Card fees are Marketing expenses supported by each line of business and/or brand.
Objectives:
– Provide a e2e system support that will allow IBM customers to decide pay their
invoices via Credit Card at the time of order or request for services (UK pilot allows for
the possibility of offering payment option via credit card to the customer after the
invoice is already billed and open on the customer account)
– Provide automated financial back end processing
– Common CC process for billing systems across all geographies

– CARS as Europe Common AR System linked to the main Revenue Streams, is the
single interface to IBM Payment Gateway (IPG) for capturing transactions
Description:
CC are handled as a method of payment in the same way as for Direct Debit, where requests for
capturing the cash are triggered only when invoices reach the AR system (or when they are
flagged as CC invoices as is the case in the UK pilot).
Credit card information should be obtained from the interested customer at the time the order is
placed, the contract is signed, and the enrolment is processed, etc. -- "up front".
A Credit Card validation check is done implying that Credit Risk is not fully covered by the Credit
Card but managed in parallel trough normal Credit Checking/customer rating procedures. After
this period of 7 days, funds are released in the customer credit card bank account, therefore if the
payment process is not completed within this time frame, there is a risk of payment failure if the
customer credit card bank account does not have enough funds when debited.
If done through the online shop, the customer directly selects the products he is interested, this
generates a URL link in which the customer introduces himself his credit card details through a
secured system. If the transaction is done through phone, the IBMer in contact with the customer
uses an Intranet tool called Virtual Terminal (VT) (requires prior request and granting of access
to enter the estimated amount to be billed (per transaction) and this creates a URL link. He sends
this URL link to the customer who enters his credit card details in a secured system. Once the
credit card transaction is authorized, returns a 13-character reference number – so-called ‘PS
Reference number’. The reference number must be entered into the appropriate application(s) so
that it appears in the first 13 positions of the relevant field in the subject system. That 13-character
PS reference number will be used by the appropriate invoicing system to designate and print the
invoice as one with a credit card type of payment, rather than one which has to be paid directly
by the customer. The 13-character PS reference number will also trigger the Accounts Receivable
system (CARS) to initiate the Funds Call Off request to IPG to charge the customer's credit card
and obtain payment.
Note: the amount charged is the total invoice amount, not the estimated amount entered into VT up front.
IBM Payment Gateway processes each transaction to the Acquirer, obtains a reply from Acquirer
and relays the response to CARS.
The UK pilot approach involves an after Invoice model. The customer can decide to pay by CC
invoices already issued in his account. The collector then enters the invoice details in VT and
creates a URL link and sends it to the customer. The customer enters his CC details in a secured
system. Once the credit card transaction is authorized and the 13-character PS reference is given,
the collectors process an adjustment in CARS, to flag the invoice as a CC invoice (the PS
reference is assigned to the invoice in the CARS adjustment). This CC flag along with the PS
reference will also trigger the Accounts Receivable system (CARS) to initiate the Funds Call Off
request to IPG to charge the customer's credit card and get payment. This pilot is active for UK
and is based on the SpareParts existing model.
Note: There is an ongoing project to extend it to other European countries where SpareParts
solution is already enabled.
Privacy/fraud prevention

Credit card numbers are considered IBM Confidential and should not be entered into CARS or
CDMS / Engage AR as actions, comments, or any other narratives, or into any other system or
database which can be viewed by other users. This is a privacy/fraud prevention measure. The
card numbers are maintained in the IBM Payment Gateway database and the 13 character
reference number are the key to the database. Currently, IBM does not accept Credit Card as a
means of payment for recurring billing (e.g., IGF Lease, Maintenance, Entitled Software).
Incident Reporting
If you suspect there is a fraudulent credit card situation, please refer to STS-D-2517
AR_Global_Credit Card Incident Reporting and follow the instructions.
Settlement
Our contracts with the credit card companies result in the actual transfer of cash occurring several
banking days after the charge is processed.
Settlement will be made, by batch interface file, from IBM Payments Gateway to CARS, for the
amount, and in the currency, of the Funds Call-Off request sent from CARS, and designed to be
generally on the day that funds are expected to arrive in IBM’s bank account. Credit Card fees
are processed separately, and are deemed not part of the AR process.
Customer Visibility of these items in AR environment
The Credit Card invoices (and payments) are on the regular customer accounts in CARS, and are
thus visible in Statement of Accounts, Statement On Line, and may be included in open item
listings on Arrears Letters. However, certain attributes of this data (payment dates, settlement
dates, etc) are deemed by IBM to be commercially sensitive and should therefore not to be
revealed to customers, so measures are taken to ‘hide’ this data in statements, generally by
replacing such dates by asterisks.
A/R Collection and Cash application
The invoicing record is passed from the Invoicing systems to Account Receivable (CARS),
including the PS Reference and the special payment identifier.
Accounts Receivable creates an open record for each record received from Invoicing systems.
A Credit Card Invoice in CARS is identified by the status code 'K'.
In the interface from CARS to CDMS / Engage AR there are fields used to inform CDMS / Engage
AR which invoices and credit notes are handled by the credit card process. These fields are:
• credit card identifier
• current credit card status
• PS reference number
CARS sends a daily batch file to IBM Payment Gateway containing all records listed as open
items. The unique PS Reference is included in each transaction as a key for PS to retrieve credit

card data logged at time of Card Verification. IPG processes each transaction to the Acquirer,
obtains reply from Acquirer and relays the response to CARS.
IPG submits a clearing file daily to the Acquirer with all CARS transactions. The Acquirer
processes the file and pays IBM merchants into designated Treasury bank accounts. At time of
payment, IPG receives a payment advice from the Acquirer, detailing each payment made. As a
result IPG generates a CARS settlement file to settle open items in CARS, and is expected to
process automatically. Credit Card Payments have a unique cash source.
A payment advice from IPG to Treasury Operations is also generated, detailing each bank deposit
made by the acquirer, excluding fees.
On a daily basis, AR collection focal points receive a report of rejected FCOs based on information
from CARS IW.
Refund process
1. Customer call IBM (Debt collection Department) to dispute a charge/invoice (in full or in
part), and thus request a corresponding credit note, and a Credit Card refund.
2. A dispute will be raised in CDMS / Engage AR and the credit approval process is initiated
when an invoice/charge is to be reversed.

3. When approved, a credit note is raised in the appropriate system with the Payment Systems
reference number and the method of payment code of the initial invoice (provided by A/R, if
it is not in the original request from customer).
4. The credit is processed, and a physical credit note is generated, the credit note record
details are sent to CARS.
5. A/R validates the credit note against the original invoice and ensure that the payment for the
initial invoice has been received, and that no credit note has been raised against before and
the request credit amount is not greater than the original payment amount.
6.1 For countries with RCO interface implemented (for the most up-to-date information on
the set of countries for this interface, please see the DOU between Spareparts and Payment
Systems). Q2C AR teams initiating the refund directly from CARS using an “R”
adjustment in “CU” CARS option.
The cc refund package needs the following additional checks to the standard ones:
- Refund Call Off Request (RCO) is done on the CARS CU screen
- It is needed to confirm that the item current C/C status is equal to ″0″ (it is needed to document
this data on the AAT package through a CARS screenshot)
- RCO requires Cash Admin approval Level 9
Important note:
Before initiating the refund the credit card reference number (from Payment System) of the
original invoice in CC status '3' has to be checked and in case of any discrepancy corrected
via Screen CT, then the refund can be requested via Screen CU.
6.2 If RCO interface is not available: Q2C (CF) AR access ePOS, and initiates a credit card
refund request with reference to the original sales order and invoice.
In both cases (refunds through RCO or ePOS), it is not permitted to refund directly to the
customer, due to the fact that the payment was made by the Acquirer, so this refund
transaction must be done via the IPG service (through RCO or VT).
Credit Card refunds should be requested, approved and documented through Adjustment
Approval Tool.
7. IBM Payment Gateways validates (real time) the credit card refund request to ensure that the
original credit card charge exists and that the amount does not exceed the original charge
amount. Payment Systems uses the above information and creates a daily batch file and send it
to the acquirer for refunds capture.
8. IBM Payment Gateway sends a response file (acknowledgment) which state successful or
failure results and corresponding bank return codes to CARS. (Refund Call-off Response)
9. The acquirer deposits the funds into the designated IBM collection bank account on the
expected payment date as advised in the deposit forecast reports. At the same time, the
acquirer sends the payment advice to IBM Payment Gateway.
10. IBM Payment Gateway generates settlement records in Payment Systems VP Report which
can be accessed by Q2C A/R for retrieval.
11. At the same time, IBM Payment Gateway sends a settlement file to CARS to close the open
item.
Q2C A/R monitors and manages the exception error handlings via CF Connect Ticket – failure
to close open items due to missing/mis-match data in CARS and CDMS / Engage AR.

Chargeback Process
Based on a customer’s dispute to a charge on his credit card, the card issuer can initiate a
chargeback, i.e. a reversal of the charge. The amount of the charge back is automatically
deducted from the next settlement. IPG will be a part of this procedure and will include the
information on the Settlement Report.
Usually, a chargeback is preceded by a request for information (RFI) process, but immediate
chargebacks can also happen when the reason for the chargeback does not require an initial
dispute. The request for information process may differ from acquirer to acquirer.
AR Collection Focal points in each country are responsible for managing the subsequent
actions.
Credit Card Cliplevels
There is a new clip level in place for Credit Card transactions:

- Invoices up to and including $50K for all Europe and MEA countries.
For invoices greater that this clip level approvals must be obtained in writing from the IMT CFO
(or designate) before the credit card can be charged.
Exceptions:
• The IMT CFO (or designate) approval is not required: for deals where credit card was
identified up front as the primary payment method and approved as part of the deal,
• direct debit payments
Responsibilities
To facilitate this procedure, IBM needs an agreement with the relevant bank to handle payments
made by procurement/credit card. This is a Treasury responsibility managed by the world wide
Payment Systems Group.
Discrepancies should be handled by the A/R Collection Focal points with the Bank or Treasury
Operations intermediary.
The AR Collection Focal point is also responsible for rejection on “fund call –off”, managing the
necessary activities and investigation and appropriated actions on CARS /Virtual Terminal Fees
booking are a Treasury Accounting responsibility, this process is not part of the AR process.
Global CF QMX:
Further information can be found in the following QMX documents:
STS-D-2555 AR_Global_Credit Card Virtual Terminal Refund Exception Process
STS-D-2549 AR_Global_Credit Card Chargeback
STS-D-2521 AR_Global_Credit Card Exception Process
STS-D-2517 AR_Global_Credit Card Incident Reporting
STS-D-2518 AR_Global_Credit Card Pending Payment URL
STS-PEF-0052 AR_HIGH LEVEL_Credit Card Pending Payment URL
https://d01db034.pok.ibm.com/q_dir/qmx/aca/qm8pl.nsf/procnum/STS-PEF-0052?OpenDocument

STS-O-1009 AR Global Credit Card Clip Level

https://d01db034.pok.ibm.com/q_dir/qmx/aca/qm8plc.nsf/89b2d3234f7e194d85256fa500669759/8dd8dc73bf4b77fb8
5257f9b002e20ab?OpenDocument
STS-D-2329 Credit Card After Invoice DLP
STS-D-2330 Credit Card Refund DLP
STS-D-2331 Credit Card Rejected FCO & RCO DLP
5.3.3.4 Electronic Payments/Bank Transfers
Currently there are no specific processes for Electronic Payment methods, outside of the Direct
Debit process detailed in Section 5.3.8., and Bank Transfers. However, e-Business is prompting
new methods to be researched.
Bank Transfers (Credit Transfers) are a form of electronic payment used in countries where IBM
has pre-arranged agreements with banks for payments (also see Refunds).
5.3.3.5 Telegraphic Transfers
Telegraphic Transfers are an occasional method of payment, normally used for significant
amounts and in respect of a specific agreement. The cost of these transactions prevents more
regular usage.
5.3.3.6 Promissory Notes
Description
This payment method is used as one way to formalize and control delayed payments, used in
circumstances where a Customer requests a delayed payment plan after receiving an invoice or
as a proposal by IBM to secure a form of payment guarantee before invoicing, where the
Customer’s payment record indicates that he cannot pay on time. Interest is added to the AR
amount to compensate IBM for the delay.
Linkages
1. Pre Legal management as one way to formalize a Debt Rescheduling case.

2. Delinquent account management, where identified as a means of handling.
3. With Treasury Operations via an automatic CARS linkage.
4. To IGF for approval as being a form of Debt Rescheduling.
Steps

a) Identification of a situation as potential for Promissory Note
• Requested by a Customer as a means of deferring payment after invoice receipt

(Rescheduling)
• Proposed by IBM as a means of handling a Customer with a poor payment record in
advance of invoicing
• Proposed by IBM as a means of handling a Delinquent account at Pre-Legal review.
(Rescheduling)
• Requested by a Customer as a means of payment.
b) Review and approval
• Each situation proposed for Promissory Note has to be reviewed and approved by Global
Financing (Debt Rescheduling approval matrix) because the outstanding amount will be
increased to include interest charges, unless the Customer proposes a Maturity Date
(Promissory note settlement date) equal to Invoice Due Date. All rescheduling cases for
Trade invoices must be reviewed in addition following the Finance Guidance FIN180
Note: For additional information about Debt Rescheduling approvals see section 5.4 Pre Legal
Administration
• For IBM proposed Promissory Notes, a formal document is produced detailing the
agreement to be dispatched to the Customer for signature.
c) The Customer or other guarantor signs and returns the Promissory Note.
d) The invoice is settled on CARS and the outstanding AR transferred to an AR ‘Portfolio’ account.
e) At Maturity Date the Customer is expected to honour the agreement through payment from his
bank account.
If the Promissory Note is honored the outstanding AR is cleared from the Portfolio account
following receipt of payment from the bank.
If the Customer does not honor the Promissory Note on settlement date (the note is dishonored),
the Portfolio account is credited and a new Open debit entry made in CARS reflecting the Due
Date as the Promissory Note Maturity date. The AR Collector or Pre Legal analyst must be notified
so that the account can be re-reviewed and a new action plan put in place.
Global CF QMX:
Handle Promissory Notes DLP (STS-D-2077):
5.4.4.5.3.4. Cash Control

Description
The following control activities comprise the required elements for good Cash Control:
Separation of handling and recording cash receipts.

Daily deposit of all cash received.

Daily and Monthly reconciliations with mismatch resolution
Cash is defined as legal tender, cheques, bank drafts, money orders, non-interest demand
deposits in banks which are unrestricted.
Post-dated cheques are not defined as Cash because they do not supply cash availability to IBM.
Steps
Any cash items either collected directly from Customers or received directly in the mail, must be
recorded for control purposes, showing:
• Date Received
• Name of Customer
• Amount and Currency of Cheque
• Action taken
• Reconciled
A local process must be defined and documented for daily depositing of all cash received in the
IBM bank account.
All cash that is received in an IBM location, should be deposited in the bank, night depository of
the bank before midnight of the cut-off date, or secured in an IBM location on the day they are
received in order to be recorded as current period cash. In addition any cash that is received in
an IBM location on or before cut-off date, and recorded in a cash receipts register can be included
as current month cash, if it is deposited in a bank at the start of the first business day after the
cut-off date.
Cash received directly by the bank, either electronically or through a locked box arrangement will
be counted in the current period if the bank processes the payment before the previously agreed
cut-off time.
Any cash received in an IBM location or in the bank in the next period will be recorded as next
period cash even if the date of the cheque or the value date is current (ie previous) period.
For additional details, please see below IBM Cash Accounting Instructions:
https://w3-connections.ibm.com/wikis/home?lang=en-
us#!/wiki/W64d0f8a882a7_40dc_adce_759fa3c0fc32/page/AI-
CASH%20001%20Cash%20Accounting%20Instruction
Responsibilities
Cash control responsibilities are held by Treasury Operations. For additional details, please see
IBM’s Corporate Instruction FIN181 (Bank Account Management):
http://w3-
03.ibm.com/ibm/documents/corpdocweb.nsf/ContentDocsByTitle/Corporate+Instruction+FIN+18
1

In some countries, specific Cash Control activities have been transferred from Treasury
Operations to AR. These activities are performed by the AR Cash Control role who cannot be an
AR Cash Administrator for the same country because of SOD issues.
Generally, the Cash Control activities transferred to AR are:

• Creation of manual payment transmittals (payments receipted not through CAT or any
other robot)
• Adjustment or deletion of payment transmittals
• ARAC and Treasury Accounting: support reconciliations with mismatch resolution
• Direct Debit set-up and management
Records
Records of all cash control activities must be kept in line with IBM’s WW Records Retention
Management Plan, and longer if required by country legal regulations.
5.4.5.5.3.5. Direct Debits
Description
Direct Debit (DD) is a formal agreement between IBM, a Customer and his Bank to transfer money
amounts on dates determined by the supplier (IBM) from the Customer’s Bank account to IBM’s
Bank account as settlement for specific identified invoices. The transfer of funds is initiated by an
IBM request to the bank. It is a highly favored method of payment because it reduces workload
for both IBM and the Customer and eliminates payment delay. In addition it can be used for
Customers with poor Credit Ratings, after approval by Global Financing, as a method of assuring
payment.
For sales made via e-Business Direct Debiting is an easy payment option, and could be
contractually linked to this type of business transaction.
Direct Debit starts with the receipt of a signed authority from the Customer containing all required
Bank detail, and ends with reconciliation of received payment against the identified invoice.
Agreements where IBM notifies the Customer’s bank, and the Customer’s bank then requests
approval from the Customer to pay are not strictly Direct Debits. These can be termed Automatic
Collection Agreements. However, most of the steps described in this section can still be followed,
with the exception of Automatic Settlement at Due Date. In these agreements AR settlement can
only be made when IBM actually confirms receipt of the cash from the bank.
Linkage
This procedure links to the AR collection process and to the Treasury Operations for Banking. In
addition, the invoicing system is required to identify such invoices in order to print a

warning/reminder legend to the Customer to advise the Customer that he does not need to pay
by normal methods, as payment will be collected via Direct Debit.
CARS set-up
CARS must be set up to handle Direct Debits, ie; Table settings & CMOD’s must be established
to design the DD selection;
CARS will select based upon:
• Either: An invoice containing a DD code set by the Billing system that matches the DD code
for that Customer in Customer Record or CARS Bank Account database.
• Or: An entry in the CARS Bank Account database which details by Customer number and
Revenue Type which invoices should be selected.
• Direct Debit Call Off/Selection date; ie daily or other DD selection (table setting). Daily
setting is strongly recommended. If frequency is not set to daily, care must be taken to avoid
impact at a month or quarter end.
• Direct Debit Leadtime; A + or - setting relative to Due Date. (CARS can select
BEFORE, ON, or AFTER Invoice Date.) This has to be further adjusted for workdays and/or
holidays.
Note: The combination of these two parameters should be carefully assessed by each country to
ensure there are sufficient days between Call Off and Settlement to allow local banking practices to
function, so that Auto-Settlement does not take place before IBM can be assumed to have received
the cash.
• A minimum invoice value at country level (zero value is strongly recommended)
• A minimum amount per bank account per direct debit type (zero value is recommended)
• A maximum amount level at Customer level (not mandatory).
CARS will not select:

• items in any currency other than ‘local’
• invoices under dispute (status code X)
• proforma invoices
• invoices previously selected for DD (including any re-instated following dishonour) unless
they have been manually re-included for a DD run in CARS by the collector
• invoices referred to an outside collection agency (CARS status code O)
• invoices with a credit note in process (CARS status code C) - For most of the countries
status code C is for WHT
• Credits awaiting refund (CARS status code R)
• invoices with an adjustment in process, ie waiting for approval (CARS status code W)
• invoices excluded for Direct Debit by the Collector (via screen Q2C)
In addition CARS can:

• select by Revenue Type per account,

• produce Direct Debit advice letters to be sent to the Customer at the time of selection
• be set to include accounts with a credit balance
• be set to include invoices with a credit balance
• be set to include partially paid invoices be set to include or exclude credit notes
Invoice Settlement
CARS settles DD invoices based upon one of 3 settings:
1. AutoSettle NOW; at Direct Debit call-off/selection time

2. AutoSettle ATDUE; at Invoice Due Date
3. Manual; After confirmation of payment received (from the Bank)
It is strongly recommended and expected that countries use option 2, AutoSettle ATDUE. This
will ensure compliance with World Trade Accounting instructions, and avoid the need for manual
allocation. However, any Agreements which do not mandate automatic debiting of the
Customers account by his/her bank, should be manually settled on CARS only when IBM has
confirmed receipt of the cash.
Steps
1. Receipt of signed and fully completed authority for Direct Debit from the Customer.
2. Set -Up
• Update CARS Customer Bank Database with the Customer’s Bank account details.
• Update any required invoicing systems changes.
3. CARS selects invoices for Direct Debit based upon the table settings and either DD
codes or revenue types, and produces 2 files:
• One file contains the DD requests which are sent via a Treasury Operations
process/program to the Banks. (Bank File)
• The second (CARS internal) file contains DD payments for settlement (DD Payment
File)
4. The Bank File is sent to the Bank which in turn sends the file data to the Customer’s
bank.
5. The open invoices selected for DD are flagged to signify that they have been selected.
6. The Payment File Automatically settles the invoices (according to table setting).
7. Treasury Operations/Accounting receives payment confirmation.
8. If Settlement is set for manual , the Bank/ Treasury Operations notifies the AR Cash
Administrator of received payments, - for a setting of ‘ATDUE’ no such notification is
required.
9. The AR Cash Administrator manually allocates the cash against the invoice.

6. Monthly reconciliations of: Cash control against IBM bank balance to ensure no variance
are performed by ARAC. Any discrepancies are investigated with Treasury
Operations/Cash administration.
Dishonored DD payments
If a Customer dishonors a DD by preventing/stopping payment from his bank, any settled invoices
must be re-instated in CARS (either automatically or manually).
Responsibilities
AR Database set-up of Direct Debit activity is the responsibility of the AR Cash Control once
notified by the AR Collector, Global Financing or Account Administration. The Cash Administrator
is also responsible for the handling and retention of the DD notifications.
Ongoing Direct Debit management is the responsibility of the AR Cash Control role. Reconciliation
of Cash Control against IBM bank balance is under ARAC responsibility.
Controls
Reconciliation of the transmittal control total from the DD Payment File added to the Cash Control
account with the IBM bank account balance to identify any DD requests not received or processed
by the bank. This reconciliation is performed by ARAC.
Global CF QMX:
Direct Debit Management non SEPA DLP (STS-D-2075)
5.4.6.5.3.6. Direct Debits - Single Euro Payments Area

(SEPA)
Description
SEPA is a the Single Euro Payments Area, and is a EU regulation issued by the Parliament of
the European Union to harmonise the way we make and process euro payments by standardising
euro electronic payments across 32 Europe countries, by enforcing the closure of national
electronic Euro payment schemes across the 32 SEPA-zone countries, in favour of schemes
based on SEPA standards. The Regulation reaffirms that for in-scope payments all banks should
use XML ISO 20022 when transmitting payments on behalf of customers.
· 27 EU Member States (DE, IE, FR, ES, PT, IT, AT, NL, BE, LU, UK, FI, EE, SK, SI, GR,
CY, SE, DK, LV, LT, PL, CZ, HU, RO, BG, MT)
· 3 additional EEA Member States (NO, IS, LI)
· 2 Non-EU States (CH, MC)

SEPA creates the following standards:
IBAN - International Bank Account Nbr (maximum 34 digits)

· 2 digit country code
· 2 digit check digit
· 30 digits (maximum) account identification --> Country Specific
BIC - Business Identifier Code (Maximum 11 digits)

· 4 digits institution code
· 2 digits country code
· 2 digits location code
· 3 digit branch code (optional)
Overview Global Direct Debit Gateway (GDDG)
As it was not possible to modify IBM's existing local Direct Debit applications to be SEPA-
compliant, a new strategic Direct Debit handling solution, the Global Direct Debit Gateway
(GDDG) has been implemented. In essence, CARS has been modified to allow SEPA-compliant
Direct Debits to be transmitted to IBM Payment Systems and called off against the in-scope
banks. Settlement details will be sent from the banks to Payment Systems and on to CARS, via
GLIM, using the mechanism already in place for credit card payments.
Whilst SEPA is applicable to all countries in Europe, GDDG is only being deployed for eurozone
countries that currently are enabled for Direct Debit business, and is currently deployed for
Austria, Netherlands, Belgium, France, Italy, Spain and Portugal. DD mandates sent to
clients include all SEPA mandatory information. For existing clients, new/revised DD mandates
were not issued, and the existing client bank data was converted to be SEPA compliant.
SEPA DD Process Description
CARS receives invoices from the invoicing applications via GLIM. DD mandate data must exist
for the DD type in CARS option 14 to enable CARS to continue with DD processing. For all DD
invoices, CARS creates a SEPA “outlook” date, which is the date that the DD is due for
payment, and which is calculated as either the invoice due date or a minimum of 14 days in the
future, whichever is the latest date. CARS also creates the DD letter for which the text is tailored
by country / ledger code, and the language is set based on the customer´s preferences.
CARS creates DD call off file and sends to IPG, via Streamserve. Once received, IPG performs
initial validation to confirm that the file structure and data is as expected.
a) If the IPG validation fails, rejections are returned from PS to Streamserve.
b) If the IPG validation is successful, PS sends the DD call-off file to the bank.
The bank validate the DD call-off file received. Any initial rejections (e.g., where they cannot
send the transaction to the client´s bank) are sent back to IPG the same day. Where rejection is
not received, it is assumed that the bank has sent the DD to the client´s bank for processing.
The bank receives DD rejections from the client's bank and sends to IPG. A client can
dishonour a DD up to 8 weeks after crediting IBM´s account without any justifications, up to 13
months if the client claims there is no mandate, in which case we should receive a query via our
bank, providing us a timeline to produce a copy of the original mandate (around 5 days to
respond).

IPG sends the settlement file (DRE) to CARS for the records it has sent to the bank, and a
rejection / dishonoured payment file (RRE) for the initial rejections or client rejections.
Acceptance of DRE/RRE files into CARS: IPG settlement (DRE) and rejection (RRE) files are
automatically processed in CARS. If CARS is unable to allocate the settlement/dishonoured
payment to an open/settled invoice, it will be loaded as a credit/debit Unallocated Cash item
(UAC) on the customer´s account.
In case the transmittal is not automatically processed in CARS and remains blocked, cash
administrators are responsible to investigate and make the necessary corrections to process it.
As the value date of the transmittal need to be within the correct accounting month, in the first
days of the month the automatic settlement is switched off. At the moment, the transmittals
created in the first day of the month with a value date in the future month need to be manually
accepted by cash controllers. To support this process, a daily email is sent from IBM Payment
Gateway which provides the value date of each settlement file.
Note: CARS team are investigating to find an automatic solution.
AR Collection Focals analyse the weekly SEPA DD dishonoured payment report, and take
appropriate actions to validate bank data with client.
CARS settlements and cash receipts from bank statement are consolidated in FDW and a
monthly cash control reconciliation performed. All mismatches are investigated and corrective
action taken.
Global CF QMX:
SEPA Direct Debit e2e Process (CF-O-0908):
https://d01db034.pok.ibm.com/q_dir/qmx/aca/qm8pl.nsf/procnum/CF-O-0908?OpenDocument
5.4.7.5.3.7. AR Accounting
Description
Overall responsibility for AR Accounting rests with Accounting. However, Q2C AR has specific
responsibilities in terms of Reconciliations and support to the process in countries. These
responsibilities are defined in a Document of Understanding entitled ‘Accounts Receivable
Document of Understanding between Europe Q2C and Europe Accounting’. This document is
maintained in the “EP & MEA STS Invoicing and Accounts Receivable” and the “CARS Central
User Group” Team Rooms, and has been distributed to all countries.
Controls
CARS-FDW Reconciliations must be completed and signed off by the Accounting Manager or
delegee (in line with the Standard for Reconciliations of Balance Sheet Accounts), and must
include identification and resolution of any discrepancies. Records must be kept for Audit
purposes.
AR teams may have to support this process, this control is owned and managed by AR
Accounting.

5.5.5.4. Pre-Legal Administration

Description
The Pre-Legal activities in the AR Process are designed to prepare identified Bad Debt situations
for a decision on further handling, reach a decision as part of the Pre-Legal review, and then track
and control the implementation of the decision through to resolution.
The decision will be based on 4 potential options:
1. To agree a new and individual payment plan with the Customer, usually a DPA (Deferred
Payment Agreement)
2. To use an external agency for the overdue debt collection.
3. To pass the situation to country’s suspense handling team for bankruptcies management
or for Litigation.
4. To write-off the debt.
This process starts when the AR Collector identifies a debt which cannot be collected by
all normal methods or where IBM is notified of one of the following events:
• Customer bankruptcy, whether voluntary or involuntary

• Customer is in receivership
• IBM Legal agrees to pursue the collection of the customer receivable and have
either file formal litigation with the courts or have ongoing negotiation/collection
efforts directly with the customer
• Business is terminated or IBM cannot locate the customer, or both
This debt is declared as a Bad Debt. It ends when the debt is settled (by collection, credit
write-off, or a combination of those). It should not normally be used for invoices still under
dispute with the Customer or in cases where IBM considers a dispute as solved but where
a customer does not agree with the solution. These later cases should go through the
claim/complaint process (see information is dispute definition in chapter 5.2.1).
The process is designed to work at a Customer level, i.e. all documentation and
consideration should be based on the total Customer situation rather than the specific
invoice(s) which are outstanding.
5. Because Pre-Legal work involves considerable liaison with Accounting, Finance and Legal
functions, clear agreement must be reached in advance to describe specific
responsibilities and organizational boundaries. Specifically in case option 3. (“pass the
situation to country’s suspense handling team for bankruptcies management or for
Litigation”) the A/R Collector will ensure the Suspense package is complete and fully
documented, prior to transferring the case.
Due to the potential impact on customer relations, Pre-Legal actions should only be
considered as a last resort to solve a Bad Debt situation.

Typical flow of activities
This process element’s feeders are:
• Failed collection activities, such as direct telephoning, arrears letters, escalations,

resulting in Distressed or Delinquent Accounts situations
• Customer Bankruptcy or Cessation of Trading
• Approved requests for Deferral Payment Agreements (e.g. promissory notes)
• Customer Dishonoring of any Deferral Payment agreement or Direct Debits
• Customer claim letter
This means that the Delinquent Management process should always be the effective process for
reaching a decision as part of the Pre-Legal review.
Output may include:
• Litigation
• Notification of Credit Risk change to Credit Management
• Suspense or write-off accounting entries on the sub ledger
• Customer Record update to show changed Customer situation
• Deferred Payment Agreements

• Data/Files for either external agencies or Legal representation, including for bankruptcies
• Approved Write-Off packages
• Registration in AR Suspense Tracking Tool (STT)
Steps
a) Preparation Responsibility: AR Collector
The AR Collector agrees with AR Squad Leader that an outstanding debt be subjected to Pre-
Legal Review only after exhausting all other methods of collection.
This includes:
 Use of all 3 arrears letters and response to any replies.
 Telephone calls, Customer visits (where appropriate),
 Escalation to relevant Marketing/Services or Channel representatives and/or their managers
and action taken in response.
The AR Collector prepares a documented package containing as a minimum:

 copies of relevant invoices
 copies of relevant contracts
 copies of relevant statements
 copies of any dispute management activity (in case this could be used by a Customer in a
legal situation)
 copies of any previous Customer Claims which were rejected by IBM, but still disputed by the
Customer.
 records of all communication and correspondence with the Customer leading to the current
situation, including details of escalations involving Customer and IBM personnel.
 any support from IBM Marketing/Services or Channels.
It should be noted that:

1. The package should be rejected by the AR Pre-Legal Analyst, or by the suspense handling
group at a later stage, if it is incomplete.
2. The AR Pre-Legal Analyst’s duties can be either concentrated on selected individuals, or
assigned at all Collectors’ level, depending on Country’s organization.
b) Evaluation Responsibility: AR Pre-Legal Analyst
The AR Pre-Legal Analyst reviews the package received for completeness, and if acceptable
takes the following steps:
1. Update CARS / CDMS / Engage AR to reflect the correct Collection Status with
appropriate flag.
CARS Suspense flagging is performed on an account level. In situations where only part of
the debt has to be flagged, a new customer account must be created and the debt, related to
the suspense situation, must be transferred to this new account. The new account is flagged
as suspense and managed by the Pre-Legal Analyst. The original account remains with
Collection.
An example of such a situation would be IBM initiating litigation against a customer because

of a contractual dispute while other contracts are undisputed and invoices, related to these
contracts are paid business as usual.
Attached below is the common flagging methodology which is based on the AP AR
classification for Suspense situations.
Business Legal Additional AR Other CARS CDMS

Category Branch CARS flag Accounting
in CARS Result
Bankruptcy 'STOP' Screen 'CP' - Suspense • requires approval Will be reflected
(= suspense R/C/L flag = L Acctg • flagged in IW automatically as
APAR/A,F) + details ('CCUARLI') = 'L' 'Legal' Flag/icon
• stops arrears letters
Receivership 'STOP' Screen 'CP' - Suspense • requires approval Will be reflected
(= suspense R/C/L flag = R Acctg • flagged in IW automatically as
APAR/B,F) + details ('CCUARLI') = 'R' 'Legal' Flag/icon
Administration 'ADMN' n/a Suspense • requires approval Will be reflected
(= suspense Acctg automatically as
APAR/C,F) 'Legal' Flag/icon
Terminated or Not 'STOP' Screen 'CP' - Suspense • requires approval Will be reflected
Located R/C/L flag = C Acctg • flagged in IW automatically as
(or Cease Trading) + details ('CCUARLI') = 'C' 'Legal' Flag/icon
(= suspense
APAR/D,F)
Litigating in court, 'LITI' n/a Suspense • requires approval Will be reflected
litigation has Acctg automatically as
started 'Legal' Flag/icon
(= suspense
APAR/E,F)
Referred to Legal n/a Screen 'CP - No Acctg • flagged in IW Payment Method

... Bad Debt ('CCUABDL') = 'Y' in Customer
or Pre-Legal for Provision • removed from Payment details
decision on indicator = Y collector and cash = 'Pre-Legal'
litigation. Litigation referral worklists (User initiated)
has not started yet
• LPC will be produced
(User guide says not)
• no refund allowed
• no IPP/DPA/Prom
note set up allowed
• registered on bad
debt provision list
Customer at risk, n/a Standing order No Acctg • flagged in IW Payment Method
i.e. classified as flag = 'Y' ('FCUASTO') = 'Y' in Customer
Distressed Payment details
= 'Distressed'
(User initiated)
2. The CARS/CDMS flagging has to be ensured to allow Accounting to consider these items
for inclusion in the bad debt reserves.
3. Credit Management might be advised in specific cases in advance to the CARS/CDMS
flagging in order to allow consider re-classifying the credit risk/rating of this Customer.

4. Updates Customer Record so that any new business transactions become Cash on
Delivery (in some countries similar process named “Blacklist” is in place).
Note: In some specific PreLegal cases, the Cash on Delivery flag would not be actioned as no
financial risk would be detected (for example Deferred Payment Agreements).
5. Requests the cancellation of any active contract (Maintenance, SW, etc)
6. Seeks a position on the account from Finance and EMEA Treasury when needed.
7. Seeks a position from Marketing, if not already received.
8. Reviews the Customer’s assets.
9. Reviews any ongoing Agreements
10. Decides whether the case is suitable for litigation in accordance with IBM Legal guidelines
in place in the correspondent country.
11. Updates the AR Suspense Management Tool (STT)
Having made a full review of the situation, the Pre-Legal Analyst makes a recommendation.
c) Recommending an Option, gaining Approvals and ensuring execution of the

decision: Responsibility: AR Pre-Legal Analyst
The Pre-Legal Analyst makes one of the following four recommendations: Approval must be
confirmed by management sign off. Different management levels and functions are involved
depending on the option described below:
Option 1 - Deferred Payment Agreement (or Debt Rescheduling)
Pre-Legal Analyst should evaluate possibilities of success of this option, and coordinate
discussion, approval and authorization of the new payment plan, including Customer signature.
A payment plan should only be offered to customers that are not able to pay due to a difficult
financial situation.
Customer adherence to the plan should be monitored and reported.
The new plan must be approved by IGF Credit upfront of presenting to the customer. Therefore
any such request for a DPA or Debt Rescheduling must be sent to Special Handling . This request
must consist of:
 1 upfront (or first installment) payment

 continuing periodical payments
 a maximum term
 a new credit rating of ‘ Cash on Delivery’ for any new Business transactions
 litigation if the Customer fails to honour any agreed payment date.
A DPA should, preferably, have monthly payments although weekly or quarterly payments could
be discussed. A DPA should preferably not last for more than 2 years (24 months).
Alternatively, Promissory Notes may be recommended for specific situations (see section 5.3.3.7).
Mandatory approvals for any Debt Rescheduling or DPA are confirmed in Appendix D.
Once approved, any change suggested by the customer before or after signing the DPA or any
second rescheduling (rescheduling of an already rescheduled AR) irrespective of the amount
requires new approvals.

 Where no interest is applied, the ‘Due Date Change’ facility within CARS should be used to
modify the due date of the selected invoices. This adjustment requires separate approval.
 Where interest is applied, the ‘Deferred Payment Agreement (DPA)’ facilities within CARS
should be used to generate the interest invoice via the invoicing system, and to convert the
subject invoices, plus the interest, into a DPA with one or more payment installments.
 Note: The DPA CARS functionality is not enabled in all European countries, so deferred payment plans
may be manually managed through due date changes and manual invoices (for interest agreed in
payment plan) could be issued via ICAT request.
Note that Rescheduling is defined as occurring when a Customer has overdue AR, and IBM
decides to amend the original payment due dates. For Commercial Financing AR, overdue is
defined as past maturity date.
Rescheduling may include the use of Promissory Notes. It is the AR Pre-Legal analyst’s
responsibility to produce and manage the execution of Promissory Notes, using the CARS
Promissory Note facility, working with the AR Cash Administrator.
If a customer has outstanding debt, at any time during the DPA process, which is not included in
the DPA the customer account remains/returns with collection. The Pre-legal analyst remains
responsible for managing the DPA but the collector is responsible for collection of any invoices
not included in the DPA. This prevents a customer’s account with aged debt being returned to
collection team, after the DPA has terminated.
Option 2 - Pass debt to External Collection Agency
If the decision is to use an external agency for collection of the debt, the AR Pre-Legal analyst
must
 update the ‘Bad Debt’ status for that customer in CARS (OCA) to
o identify the selected Agency

o prepare documentation, and ensure it is received safely by the agency.
Progress must then be monitored closely by the Pre-Legal analyst over the agreed timescale, and
support should be provided to the agency where appropriate. This support
may include provision of additional documents, acceptance of payment, cash allocation. In
addition controls and reports must be produced documenting the progress.
If the Agency is unable to force settlement of the debt in the agreed timescale (which should be
a maximum of 3 calendar months from acceptance) the situation should be re-reviewed to
determine if Litigation is required.
Agreements with External Collection Agencies will normally be made by IBM Purchasing, but as
a minimum such agreement should include:
 Fee structure basis
 Payment methodology
 Documentation to be provided

 Methods of review and communication
The use of an External Collection Agency has to be decided by the country CFO upon request.
Any contracts with external agencies should be negotiated between the agency and IBM
Procurement.
Option 3 - Instigate Litigation
If the decision is to instigate Litigation, the following actions must be taken:
1. The Pre-Legal analyst has to prepare the package to be referred to the suspense
handling group for final decision.
2. The Pre-Legal analyst has to update CARS / CDMS / Engage AR to reflect the
customers’ bad debt status as ‘referred to Legal’. If the account will be moved to an
external Agency this has to be reflected in the CARS OCA Status. It’s essential for
further actions to perceive the acceptance from Legal.
3. The Pre-Legal analyst must ensure that all conditions and all approvals required for
moving an account to Suspense and coding it accordingly in CARS are met and
secured, in accordance to APAR: https://w3-connections.ibm.com/wikis/home?lang=en-
us#!/wiki/Wc969f0323dad_42f6_ba75_d1369e3fe646/page/AP%20by%20Topic
APAR Suspense conditions:
A. Customer is bankrupt, whether voluntary or involuntary and IBM is prevented from

initiating independent litigation due to the laws of the respective country;
B. Customer is in receivership and IBM is prevented from initiating independent litigation
due to the laws of the respective country;
C. The court has assigned a customer's assets for the benefit of creditors;
D. Customer business is terminated or IBM cannot locate the customer, or both;
E. IBM Legal has formally informed (provided written documentation) to ISC/CF that IBM
Legal and/or outside counsel retained by IBM Legal agree to pursue the collection of the
customer receivable and have either filed formal litigation with the courts or have
ongoing negotiation/collection efforts directly with the customer. IBM legal will determine
which customer receivables are impacted by the litigation. (e.g., all of the customer’s
receivable may not be a part of the litigation);
AND:
F. ISC/CF is legally or formally prohibited from continuing normal collection efforts
When a legal bankruptcy has not yet occurred, the following written approvals must be
obtained before transferring balances to suspense:
· Country legal
Note: In the case of either a legal bankruptcy action on file with the courts or a litigation request
accepted by IBM legal, and meeting the criteria set forth above, Q2C AR will place the customer's
impacted A/R into Suspense directly and send formal notification to both the country/brand
Finance CFO (or designee), country Legal and Accounting of the action taken.

Country Legal would be required but in the case of either a legal bankruptcy action on file with the
courts or a litigation request accepted by IBM legal, and meeting the APAR criteria set forth above,
Q2C AR will place the customer's impacted A/R into Suspense directly and send formal notification
to both the country/brand Finance CFO (or designee), country Legal and Accounting of the action
taken.
A case can be coded as suspense not only if the formal litigation has commenced in the Court but
also if Legal is under negotiations or having collection efforts with the customer (Timing for criteria).
Q2C is responsible for chasing the appropriate approvals and/or confirmations.

A maximum response time of 10 business days is expected from Legal to provide a position back to Q2C in
case written & explicit Legal approval is solicited.
1. When APAR Suspense conditions are met, the account has to be transferred to Suspense.
The transfer to Suspense has to be updated in CARS through the process code ‘L’.
2. Provide ongoing support to the lawyers during the litigation process.
3. Tasks belonging to the Suspense management groups include: Review progress

regularly; Internal Recovery support: coordinating the formal collection of IBM products for
which the Customer refuses payment, and where repossession is legally enforceable;
Monitoring bankruptcies, including regular reviews with any appointed Administrators
and/or Dun & Bradstreet, and coordinating any contract closure activity with contract
management functions. Receivership contacts should be reflected for customers in this
status via the appropriate CARS Bad Debt (CP) screen.
4. It is imperative that all countries use this method of identification for accounts classified
‘with Legal’, both for AR Accounting reasons and for easy identification in AR reporting at
Europe Level.
5. Each suspense account must be registered in the AR Suspense Management Tool (STT).
6. The suspense flag should be removed if the suspense case has terminated in order to
avoid that new potential invoices will be coded in Suspense when this is not correct. The
only exception to this guidance are bankruptcies, liquidations and ceases of trade: There
the code is maintained to reinforce the flagging of those situations and avoid any new
invoice may be issued.
Option 4. - Write-Off
If the decision is to write-off the debt, the AR Pre-Legal analyst prepares a package and initiates
the Write-Off Adjustment in CARS. The Pre-Legal Analyst also raises the Write Off request in the
Adjustment Approval Tool (AAT) to obtain the required approvals.
d) Registering Suspense Accounts in AR STT Responsibility: AR Pre-Legal Analyst
If an account is transferred to suspense it also has to be registered in the AR Suspense Tracking

Tool (STT). AR STT allows for automated follow up of suspense accounts. At the same time, AR

STT functions as a repository tool for suspense accounts. The AR STT has been deployed in EP
& MEA
e) Reporting Responsibility: AR Pre-Legal Analyst
Reports on Pre-Legal situations must be prepared monthly for the country Credit Committee, and
to ensure reconciliation for accounts subject to suspense accounting.
COD & Black List process principles
Introduction:
The following section aims to describe the AR process steps followed in Europe, CEE and MEA
countries to highlight customer accounts where bad payment behaviour has been detected by the
AR teams. Consequently, a financial risk has to be taken into consideration in case any new
business would be requested.
These financial risk scenarios are flagged using:

- The Cash On Delivery flag (COD): A specific set of value/s in Customer Master Record
(CMR) is/are reserved to be used for this purpose (these values and fields are different at
country level). This flag in CMR should automatically flow to other systems as Global
Credit Checking Tool (GCS).
This is the flag in place for Europe IOT countries and South Africa.
- The Black List: A list of customers is maintained by AR. This list is not linked with any
other system.
This solution is used in CEE and MEA countries (except South Africa).
This guidance only intends to describe the AR responsibilities. Other functions involved have
documented their responsibilities in their own process documents (for example, in their
processes, the Credit Checking team has documented that the COD/Black List information has
to be taken into consideration during Credit Checking assessments).
Important note: The Business (the Requester of the deal and/or Opportunity Owner) is the ultimate
responsible function to ensure that all convenient checks have happened to avoid that a deal would be
approved without the acknowledge of any potential financial risk indicator as the COD or Black List one.
The Country AR manager finally is responsible for the following process steps. He/she can
appoint a “COD/Black List Coordinator” who will coordinate them on his/her behalf. These
activities are not in conflict with any of the standard AR roles.
In Europe IOT countries most of these activities are already assigned to the PreLegal Analyst
role.
1. Including a customer into the Black List/Flagging a customer as COD
The AR Collector and/or PreLegal teams identify situations that trigger the customer inclusion in
the Black List or the flagging of a customer as COD.

*SoftLayer, SaaS and MSS is excluded from this process.

These situations can be categorized as follows:
1. Cases to be immediately included in the Black List/flagged as COD and no approval is required:
- Customers that have fallen under any of the APAR Suspense scenarios
- Customers where a Bad-debt write off has been requested
Note: Please note that not all write offs would require inclusion of the customer in the Black List
or the flagging of the customer as COD (it might be some write off caused by other root causes
than pure bad debt ones)
The AR approver/s for write offs needs to ensure that the customer is black listed or flagged as
COD in case that the write off is caused by a bad debt situation.
- Customers sent to an OCA
2. Cases that require Country AR manager approval:

- Ad hoc requests from the Collection - or any other team (i.e.: Special Handling, IGF, etc.) based
on a different root cause other than the ones described in point 1.
- Any other potential bad-debt behaviour indicator that the AR management can decide to
implement (for example the review of customers with over90 debt)
All these cases should be addressed to the Black List/COD Coordinator who will check the
evidences proving the situations explained above and documentation of the AR management
approval for cases listed in point 2.
In case of COD countries: The flagging will be requested to CMR through a request in JIRA by
AR Collectors and/or Pre-Legal teams CMR teams are responsible to flag/unflag a customer as
COD in the CMR systems.
In case of Black list countries: The Black List Coordinator will include the new customers in the
Black List and share this list at least quarterly with the credit teams by loading the file into a shared
box folder.
In case that AR is requested to evaluate a COD/Black List removal: These requests have to be
evaluated and approved by AR management. It is not possible to remove a COD flag or customer
from the Black List under any of the APAR Suspense scenarios.
Note: It is recommended (especially in CEE and MEA countries) to inform the country CFO and the
corresponding Sales responsible for the affected customer in relation to any addition / removal from the
black list including an explanation.
Measurements
No specific measurements.
Controls

Records must be maintained of all items received by Pre-Legal, detailing what action is taken,
recording progress and status, and describing how each item is resolved.
In particular the correct method of identifying Customers in Legal or OCA status (with or without
suspense accounting) must be used and reviewed in countries, to ensure correct accounting, and
the suspension of Late Payment Fees, Arrears Letters (OCA only), and any Refunds.
Note: All the expenses related to the handling of Pre-legal and Legal for accounts falling into Suspense
should be properly booked in the SGA-Minor Account 0310.
Global CF QMX:
Further information can be found in the following QMX documents:
- Pre-Legal Activities DLP
- Cash on Delivery (COD) and Black List DLP
- Use of A/R Suspense Tracking Tool (STT) DLP
5.6.5.5. AR Planning
Description
Management of the AR Process requires careful planning. Planning objectives are:

 Improvement of AR & Collection performance
 Improvement of AR Analysis
 Provision and accuracy of AR data
For this purpose AR Planning sets operational AR targets in-line with the DSO targets provided
by EHQ as well as monitor, forecast and analyze the AR related parameters.
5.6.1.5.5.1. Setting Targets and Objectives
Target Reception and Plan Construction
EMEA Treasury will provide quarterly and yearly regional (IMT & EBU) targets. Once received
these targets should be assessed by the parties involved using data provided from previous
performance, expected business achievement and ongoing AR initiatives. Subsequent to it AR
Planning sets the operational AR targets.
Plan Cascade
The operational AR targets must be in-line with the financial DSO Target requirements and
include following metrics:

• Total Delinquency (TD) :

Measures the absolute $’s on file older than 30 days (APAR calculation method).
The target represents the maximum $ amount that can be left on the file for this metric at the
end of the measured month.
• Aged >90 :
Measures the absolute $’s on file that will be over 90 days old (APAR calculation method).
The target represents the maximum $ amount that can be left on the file for this metric at the
end of the measured quarter.
• Aged Items (>150 days) :

Measures the line items (billed invoices, cash payments and credits) older than 150 days
(real aged, not APAR) expresses it as a % of total line items on file at the beginning of the
month and due within the measured quarter.
The target represents the maximum number of over150 days old items (expressed as % as
defined before) that can be left on the file at the end
Both AR Collectors and AR Cash Administrators have to measure contributions towards

overall target achievement.
Performance Tracking
Dashboards are presented on a regular basis for tracking AR performance against plan, and
updating the AR forecast as appropriate. In addition trends should be analyzed on regular basis
so that the Operational Plan can be fine-tuned during the course of a month or quarter.
By consolidating internal AR targets, objectives and incentives, a consolidated Country AR

forecast is tracked and monitored throughout the target period.
Results
At the end of each month or quarter, performance results must be produced to review each and
every target and objective set. This should also apply to any Incentives set, within Q2C AR and
at Sector/Brand and Executive level.
Reconciliation
Support reconciliation with Accounting results (if needed) is performed according to the DoU
‘Accounts Receivable Document of Understanding between EP & MEA STS (CF) and EP &
MEA Accounting’.
The DoU between Q2C AR and Accounting is stored in the ISC A/R Planning Teamroom.
5.6.2.5.5.2. AR Data Coordination

The AR Planning function includes the coordination and supervision of all agreed operational
reports requested to support the country/geography A/R organization performance.
5.6.3.5.5.3. Process linkage and Management

Cross-functional process linkage
There are additional, key requirements to link all the functions involved in AR Process together
during performance periods.
These functions normally are:

 Finance/Treasury
 Accounting
 Global Financing
 The Brands and Sectors
 Global Services
 Subsidiaries
 Other Q2C Functions
 Business Controls
 Legal
 Contracts and Negotiations
The AR Process cannot be performed effectively unless all these functions work together and
maximize country performance against the Plan and the Forecast. Therefore, - in addition to
comprehensive publication of targets / objectives to key functions and business as usual
communication -, the following formal meetings must be arranged as part of the overall AR
process management system:
 Country AR Committees
These committees should meet regularly and consist of Q2C, Finance, Treasury,
Brand/Sector representatives, Global Services and Global Financing, with the objective
of dealing with Operational matters on issues and procedures.
 Country Credit Committee

The Credit Committee is the decision making group for Accounts Receivable. It should
contain country Executive Management or fully delegated deputies for Q2C , Finance and
Treasury, and decide matters of Escalation, Bad Debt, Creditworthiness, Write-Off,
Litigation, Incentives, Revenue Reversal, Pre-Legal and Debt Re-scheduling. In addition this
Committee should take the responsibility for ensuring World-Wide Payment Terms are
adhered to, and agreeing and submitting any deviation requests to Europe. The Committee
should meet monthly for the first two months of a quarter, and fortnightly in the last week of
a quarter.
AR Project Coordination
Any Europe & MEA or Country projects on AR should be coordinated and led by the AR
Process and Business controls group. This includes:

 Review of country processes against identified best practices

 Support to AR Management in analyzing base coverage requirements; best use of
Collectors in Tele coverage, arrears letters against the current strategy etc.
 Deployment of agreed AR productivity tools
5.7.5.6. AR Testing and Compliance

Controls include:
 Separation of Duties
 Process controls and Documentation
 Self-Assessment and Audit support
 Audit requirements
 SOX Key Control Testing
5.7.1.5.6.1. Separation of Duties

Billing data is passed to AR under transmittal control to ensure the receipt of all invoices and
credit notes issued, and to provide a means of mechanized reconciliation to the General Ledger.
Any errors detected by CARS are retained in an Input Control database. Billing corrections must
only be performed by the Billing function.
Treasury Operations provides AR with batched cash receipts under transmittal control.
Corresponding remittance advices should be forwarded to the AR Cash Administrators for
allocation against identified invoices and credit notes on Customer accounts. The Payment
transmittal is used for reconciliation to the General Ledger, and for balancing each processed
batch. Within the AR function a documented matrix should ensure separation of duties for ALL
required approvals, by showing separate:
Roles:
 Collector
 Dispute Initiator
 Dispute Manager/ Dispute Coordinator
 DRO/ Dispute Processor
 Cash Admin, Cash Entry
 Cash Control
 P & BC
 Pre-legal
 Planning
 Management & Team leading
 AR SMART Team
 AR Systems Support

Responsibilities:
For further information related to CARS adjustments in terms of the roles initiating and
approving the adjustments, please consult the Common EP & MEA Process Appendices
document – Appendix E
Global CF QMX:
Common Europe AR SOD Matrix (CF-O-0319):
http://d01db034.pok.ibm.com/q_dir/qmx/aca/qm8pl.nsf/procnum/CF-O-0319
FIN 183 have been sunset and SOD contents have been replaced by FIN 182 appendix C. SOD
assessment is performed in line with the Global QTC SOD guideline.
5.7.2.5.6.2. Process Controls and Documentation
Any country AR process deviations to the Standard EP & MEA AR Process must be documented
and approved as outlined in chapter 2.4. The Process must be readily available to all country AR
personnel, owned locally by the country AR Process Owner and regularly reviewed and updated.
Process control points must be identified and used by the AR Management for regular
documented reviews with AR Process and Testing and compliance Team, which supports the AR
Managers on all matters concerning these topics. If necessary, this review can be used to educate
end-users and management on control changes and exposures.
Process & Business Controls documentation should include an up to date Separation of Duties
Matrix which demonstrates roles and responsibilities for all personnel with Accounts Receivable
system accesses. In case of a multi company environment, potential different roles/ accesses by
one employee per company have to be considered and included accordingly.
5.7.3.5.6.3. Self-Assessment and Compliance Test
The Process must be compliance tested every quarter.

Documented records of findings, trends, management reviews and actions taken must be
maintained.
The AR process is subject to the Management Self Assessment of Controls (MSAC). This is a
single control program with 4 reporting cycles centered around a continuous controls process
and aligned with the Quarterly Certification of Management (QCM) reporting cycles.
5.7.4.5.6.4. Audit Requirements

Documented evidence must be maintained in line with IBM’s WW Records Retention

Management Plan (http://w3-
03.ibm.com/ibm/documents/corpdocweb.nsf/ContentDocsByTitle/Corporate+Instruction+CIO+1
22) (or longer if required by a country legal/ fiscal requirement), for:
• All identified Bad Debt situations, showing action taken up to resolution.

• Reconciliations, using the system generated reports, showing action taken to resolve any
discrepancies
• All adjustments, including write-offs and refunds, showing action taken and authorized.
• Compliance testing, showing sample size, findings, trends, and action taken.
• Dispute resolutions.
• Collection activity for delinquent accounts, showing action taken, including escalation.
• Promissory Notes
• Late Payment Fee exceptions and cancellations.
• Unallocated Cash control and resolution actions.
• Any WWPT deviation approvals from Europe and Corporate.
• KCFR Testing documentation must be maintained for current plus 7 years based on IBM’s
current Records Retention policy.
• KCO Testing documentation must be maintained for current plus 1 year based on IBM’s
current Records Retention policy.
5.7.5.5.6.5. Sarbanes Oxley

The Sarbanes Oxley (SOX) set of testing & reporting is a mandatory corporate requirement for
those countries in scope, which need to be certified on a regular basis.
• Details on the general program can be obtained from Europe & MEA Q2C Business
Controls
• From an Invoicing & A/R perspective, a single template has been created to cover the
Invoicing and Accounts Receivable Key Financial Control Points, autonomously from the
various Revenue Streams
• Countries in scope are expected to use this single template in defining their local SOX
program, in order to keep country variances to a strict minimum, to rely on Europe & MEA
Invoicing & A/R Vertical for any template design concern or issue arising from a country
review (Certification, Audit, CAR, etc.) and focus on adequate testing & eventual
remediation.
Key Control Testing
The following template applies to all countries subjected to KCFR/ KCO reporting requirements
and gives a high level overview of the controls to be executed and reported within WWBCIT
All details of the controls are contained in WWBCIT
The applicable sample size for the AR testing has to be aligned to the minimum levels required
by Corporate Business Controls (CBC):

https://w3-connections.ibm.com/communities/service/html/communitystart?communityUuid=e06fd74f-
9380-4c76-9fdc-a81a3ba1698b
The Business Controls Prog. Manager Q2C AR & Invoicing Europe / MEA should consider
severity of risk in making his/her recommendation to be finally approved by the Europe & MEA
AR Process owner.

Control Points Objective

KCFR 101 Ensure invoicing data completeness and accuracy - all billing data has
Invoicing Data Completeness and been received in the invoicing process all invoicing data has been
Accuracy processed and transmitted to downstream processes
KCFR 102 Ensure SOD matrix is documented, reviewed and approved by
Separation of Duties management annually or as staff responsibilities change. Validate that
appropriate actions were executed to eliminate or mitigate risks
associated with separation of duty conflicts.
KCFR 103 Ensure Accounts Receivable data completeness & accuracy – all
AR data completeness and invoicing data has been received in the Accounts Receivable
accuracy
KCFR 104 Cash input Reconciliation to ensure Cash entered in Accounts
Cash input reconciliation Receivable system balances with Cash Delivered from bank and / or
Treasury Operations
KCFR 106 Refunds , concessions and/or bad debt ( via write offs ) = ensure all
Financial adjustments (Refund & processed are valid & have been correctly approved
Write-off)
KCFR 107 Transfers to Suspense = ensure all transfers to Suspense have been
Transfer to suspense correctly processed, & authorized
KCFR 108 Identification of Doubtful Accounts via the aged debt data (to ensure
System invoice aging accuracy correct Reserve calculations)
Control Points Objective

KCO 506 Ensure customer accounts are accurate and balances that are cleared
Non financial adjustments from the A/R file via A/R File Adjustments, are appropriate and have
been authorized
KCO 521 Cash application to ensure manual application and/or manual
Accuracy of manual cash exception to the auto cash has been correctly and promptly applied to
application customer accounts and actively followed up
Note: Since the transfer of IGF out of Q2C AR teams, Testing and compliance testing
only performs testing on KCO104 for IGF as there is no way to split Trade from IGF in
CAT.
5.7.6.5.6.6. CCM Process (Continuous Controls

Monitoring)
Description
CCM is a tool aiming to add an even better Business Controls posture to our AR Process. It
comprises a suite of reports to highlight all high risk transactions on file and identify any potential
exposures. With the tool we gain the benefit of real-time identification of any potential control
deficiencies within our processes.

5.8.5.7. File Maintenance
5.8.1.5.7.1. Adjustments
Description
The following adjustments can be made to CARS ledger entries:
Adjustment Usual trigger within the AR process

1. Apply - Apply invoice / credit note acc. credit note text
- Apply invoice / credit note acc. remittance advice from 'date'
- Apply invoice / credit note acc. phone call with customer on 'date'
- Apply invoice / credit note acc. mail from customer from 'date'
- Apply invoice / payment acc. remittance advice from 'date'
- Apply invoice / payment acc. phone call with customer on 'date'
- Apply invoice / payment acc. mail from customer from 'date'
- Apply invoice / credit note acc. information from collector (provided
remittance advice) from 'date'
- Apply invoice / credit note acc. information from collector (mail from
customer) from 'date'
- Apply invoice / credit note acc. information from collector (phone call
with customer) from 'date'
- Apply invoice / credit note acc. information from collector (credit note
text)
- Apply invoice / payment acc. information from collector (provided
- Apply invoice / payment acc. information from collector (mail from
- Apply invoice / payment acc. information from collector (phone call
2. Unapply (settled items) - Unapply invoice / credit note acc. to phone call with customer on
'date'
- Unapply invoice / credit note acc. to remittance advice from 'date'
- Unapply invoice / credit note acc. mail from customer from 'date'
- Unapply invoice / payment acc. to phone call with customer on 'date'

- Unapply invoice / payment acc. to remittance advice from 'date'
- Unapply invoice / payment acc. mail from customer from 'date'
- Unapply invoice / credit note acc. information from collector (phone

call with customer) from 'date'
- Unapply invoice / credit note acc. information from collector provided
- Unapply invoice / credit note acc. information from collector mail from
- Unapply invoice / payment acc. information from collector (phone call
- Unapply invoice / payment acc. information from collector provided
- Unapply invoice / payment acc. information from collector mail from
3. Reject a Late Payment Fee - Late Payment Fee Proposal based on Payment arriving late from
Proposal customer side (Rejections have to be done in line with the LPF
Rejection matrix, mentioned in the appendix document).

4. Settle an item and process an - Input / Agreement from IBM Accounting

account entry for it to a specific - Country Specific bookings in accordance / agreement with IBM
Accounting
general ledger (General Ledger
adjustment)
5. Process a Refund - Credit Situation on Customer account (Double- or Overpayment,
Credit Note)
- Customer Request
6. Process a Write-off - Collection activities are exhausted
- out of Delinquent / Distressed / Suspense Account Management
(e.g. a customer is bankrupt,..)
7. Reverse a Write-off - incorrect WO adjustment performed (e.g. when it is needed to write-
off an item via General Ledger adjustment, but a W was performed)
- customer pays an Invoice that was written off previously
8. Penny Elimination / Reverse - Underpayment as financially not viable to collect (or reversal
Penny Elimination
9. Move an Item (Open items only), - Move of payment from dummy account to correct account acc.
i.e. to a different customer number phone call with customer on 'date'
- Move of payment from dummy account to correct account acc.
remittance advice from 'date'
- Move of payment from dummy account to correct account acc. mail
from customer from 'date'
- Move of payment from account XXX to account YYY acc. to phone
call with customer
information from collector (phone call with customer) from 'date'
information from collector (provided remittance advice) from 'date'
information from collector (mail from customer) from 'date'
- Move of payment from account XXX to account YYY acc. Information
from collector (phone call with customer) from 'date'
- Move of payment from account XXX to account YYY acc. Bank
Statement (wrong allocation done)
10. Due Date Changes - Due Date Change acc. contract 'Number'
- Due Date Change acc. to the invoice
- Due Date Change acc. approved Payment Plan
- Due Date Change acc. to installment invoice (IPP)
- Due Date Change acc. To PO (if previously approved by Contract
Management)
11. Process an exchange - Payment in different currency
Adjustment
12. Cross Ledger Adjustment - Applies over two Ledger Codes (for applicable countries and specific
payments. Not permitted for credit notes unless Country Taxes
states is correct and possible from Taxes/VAT standpoint with no
issues)
Details on how to process each adjustment can be found in the CARS User Guide.
Table setting in CARS controls approval levels for administrators through combinations of
 Security Level
 Update Authorization
 Maximum Adjustment amount
 Approval Flags for each type of adjustment.
These approval levels must be defined and documented for each country as part of the overall
AR controls and separation of duties matrices.

Responsibilities
Adjustments should be raised depending on the type of Adjustment e.g. by AR Collectors/ Pre-
Legal Analysts or Cash Administrators and approved by AR Squad Leads/ AR Iteration Managers
or Cash Control.
The Common Adjustment Approval set-up can be found in Appendix E.
Controls
Separation of Duties between Adjustment initiators & Adjustment approvers, depending on the
approval levels which might vary for each adjustment.
All adjustments must be reconciled monthly between CARS & the ledger.
5.8.2.5.7.2. Refunds
Description
A refund is defined as a payment made in favor of a Customer in refund of an agreed credit
balance or overpayment situation on CARS. The procedure starts with a formal request from a
Customer or potential refund identification by a Cash Administrator within the application of cash
/ unallocated cash management process and ends with the dispatch of a cheque or bank transfer,
and the settlement of the Open credit balance item on the ledger.

Refund Process
Customer Unallocated
Cash
requests Cash
Application
Refund Management
Cash Admin
identifies potential
Refund and
informs the
responsible
Collector
Are open items

on the customer Yes
No account?
Contact customer
to obtain
remittance
information
Remittance
No information Yes
received?
Contact customer Does situation Proceed according

for obtaining justify exceptional remittance
written Yes refund? information
No
confirmation / or
follow negative
approval process
Initiate Refund Unallocated

Adjustment in Cash
CARS Management
Prepare approval
Yes request utilizing
the AAT
Have all
No approvals been Yes
given in AAT?
Is reason for
Cash Admin
rejection just
Manager validates
missing/ wrong
refund request
information? No
Is information
No Yes
valid?
Cash Admin Cash Admin
Manager rejects Manager approves
Delete Adjustment
adjustment in adjustment in
in CARS
CARS & informs CARS & informs
collector collector
1. Either the Cash Administrator identifies a potential refund situation coming from
the Cash Application or the Unallocated Cash Management Process, which results
in an information to the responsible Collector by mail, or the Collector gets a direct
request from the customer within the Collection Process
2. The responsible Collector analyzes the customer account statement with regards
to open invoices

a. If open invoices do appear on the customer account, contact the customer

in order to obtain remittance information for the unallocated cash
i. If the customer does provide remittance information, proceed with
applying the cash to the open item(s) according the provided
information
ii. If the customer does not provide remittance information, check if the
situation can be classified as an exceptional situation and
consequently would justify to proceed with a refund
1. If there is no justification to proceed with the refund on an
exceptional basis, continue with Unallocated Cash
Management
2. If there is justification to proceed with the refund on an
exceptional basis, continue under b.
b. If open invoices do not appear on the customer account or an exceptional
situation to proceed with the refund is given and the refund is in
accordance with Corporate Instruction FIN184 not preventing any refund:
https://w3-
03.ibm.com/ibm/documents/corpdocweb.nsf/ContentDocsByTitle/Corporat
e+Instruction+FIN+184
i. contact the customer in order to obtain written confirmation to
proceed with the refund (this should be by letter/e-mail or fax, and
should provide the cheque payee information or the bank account
information to which any credit transfer should be made).
In case that the Collector would receive the customer’s confirmation
through a phone call , and in order to minimize the business controls
risks associated with refunds while containing the workload
associated with chasing the Customer’s confirmation, it is acceptable
to replace the formal written Customer confirmation by a “negative
confirmation” that can be issued by IBM through letter, e-mail or fax,
for all refunds below a certain amount (this amount should be
determined and formally documented by country, but in any case
should not exceed the equivalent of 15 K€ without prior approval
according Deviations process as outlined in chapter 2.4. The
"negative confirmation" issued to the customer must specify that,
without any answer within 8 business days, IBM will proceed with the
refund. The information provided to the customer should contain as
a minimum: refund amount, invoices/credit notes numbers if any,
reason for refund (overpayment, payment twice, credit note, account
creditor) and mode of refund. “Negative confirmation” documentation
must be retained along with the other Refunds documentation for
audit purposes.
ii. The Collector initiates the Refund Adjustment in CARS
iii. Prepare request for obtaining the approval which is necessary
according delegated clip level and in line with FIN101 (refund
approval matrix can be found on Appendix D) through the Adjustment

Approval Tool ( AAT ) which is a workflow notes database to support

the refund approval process,. This must contain:
• The payee (Customer) name, address,
• The Customer IBM account number
• The Customer’s Bank Account number
• The exact amount and currency of the agreed refund
• The written confirmation from Customer or negative confirmation
• Print screen of the Adjustment initiated in CARS
• Proof of the Credit situation on CARS. This
should include a review of the total
Customer entity to ensure there are no
accounts with debit balances where the
credit could be used (with prior Customer
agreement), to settle Open items.
• In case of no credit situation in CARS, justification for this
exception
• For manual cheques the information about the detailed address,
when different to the one in CARS (including the explanation/
justification for not using the address in CARS) in written form
from the customer
• In case of write off performed in the last six months an
explanation for Refund is needed (this check is only valid for
countries where write off is performed in CARS through "w"
adjustment and therefore CP screen shows the account’s write
off historic record)
• In some situations it may not be possible to refund Credit Notes
(e.g. items raised with Credit Reason Code B2 in France),
therefore Collectors should check copies of credits in Image
before refunding.
If the Credit Note copy clearly states that an item cannot be
refunded, the request may be cancelled / rejected.
iv. Once inserted the request is submitted for approval within the AAT
1. If the request is approved inside the tool, the initiated
Adjustment in CARS is validated against the approval
package by the Squad Leader (or Iteration Manager, or
delegate)
a. If all approvals have been correctly obtained and the
adjustment is matching the request, the corresponding
adjustment is approved in CARS, which results in
processing the refund to the Treasury Operations
Systems (if manual intervention is needed, approval
will be granted in CARS once it is confirmed that refund
information has been received in Treasury Operations
system). Following the approval the corresponding
Collector is notified.

b. If any mismatch is detected, the adjustments gets

rejected in CARS and the responsible Collector gets
notified.
2. If the request is not approved inside the tool
a. In case the rejection is based only on missing
information, the Collector has to create a new request
inside the AAT, including the additional information as
required.
b. In case the rejection is based on business reasons, the
adjustment has to be deleted in CARS by the Collector
upon notification.
Further Guidelines:
As per FIN 101 instructions, refunds below 5K require the approval from one authorized
approver and those over 5K, two authorized approvers are required.
In both cases at least one of these individuals is to be an authorized approver. An
authorized approver is a first line manager or higher. However in specific cases (holidays,
sick leaves, etc) a second line manager or higher may grant exceptions to this
requirement by designating a non manager as an authorized approver.
No Cash refunds are allowed.

If AAT is not available for a significative period of time, the process as outlined above
has to be followed accordingly, storing the mandatory documentation and obtaining the
necessary approvals by mail.
For Refund related to “Credit Card” payment, please see section 5.3.3 Alternative
Payment Methods.
Responsibilities
Identification of a refund, obtaining Customer approval and submission of the request for
approval in the AAT is the responsibility of the AR Collector, though potentially
communicated for further evaluation by a Cash Administrator coming from the
Unallocated Cash Management Process. The submission of the approved request to
Accounts Payable / Treasury Operations, and settlement of the Open item on CARS are
the responsibility of the AR Squad Lead or delegate. For certain Europe countries a
common delegation Matrix, as appearing in Appendix D has been established. For the
countries not yet mentioned in the matrix, the local procedures, respecting FIN101, have
to be followed.
Controls
Documented copies of requests and approvals for refunds must be maintained in line with
IBM’s WW Records Retention Management Plan, and longer if required by country legal/

fiscal regulations. This evidence is stored inside the AAT tool, following the mentioned
rules.
Global CF QMX:
Further information can be found in the following QMX document:
Adjustment Approval Tool (AAT) - Refunds and Write-offs (STS-O-0991)
5.8.3.5.7.3. Write-offs
Description
An AR write-off is defined as any debt entry processed to clear an otherwise irresolvable

variance or to correct an inaccuracy on the customer account due to situations such as
obsolescence, or uncollectability. A write-off may also be appropriate when the cost to research
and clear an item exceeds its value and therefore any further action would be unproductive.
Prior to processing any write-off, every reasonable attempt must be made to clear the item
through normal processes on a timely and accurate basis. Therefore it must be demonstrated
that all possible courses of action have been explored and exhausted, and the write-off
consequently is justified.
Approved AR items are written off after review and justification when it is decided that no
alternative action is suitable or possible. In addition to the formal Write-Off procedure, countries
may choose to automatically write-off small balances (credit or debit) arising from cash
allocation and adjustments on CARS, or from the Customer’s account balance of items over a
certain age. The maximum values of these automatic transactions are table-set at country level,
but must be pre-approved by EMEA Treasury and Finance.
.

Write-Off Process
Delinquent/ Suspense/
Collection Distressed Pre-Legal Special
Process Management Process Handling
Process Process
Initiate Write-Off
Adjustment in
CARS
Prepare approval
Yes request utilizing
the AAT
Have all
No approvals been Yes
given in AAT?
Is reason for
Cash Admin
rejection just
Manager validates
missing/ wrong
Write-Off request
information? No
Is information
No Yes
valid?
Cash Admin Cash Admin
Manager rejects Manager approves
Delete Adjustment
adjustment in adjustment in
in CARS
CARS & informs CARS & informs
collector collector
1. Starting with a proposed Write-Off, coming from the Collection, Delinquent/

Distressed Management, Pre-Legal or Suspense/ Special Handling Process, the
Collector or the Pre-Legal Analyst initiates the Write-Off Adjustment in CARS (if
initiation is done by the IGF Special Handling Analyst, the initiation of the
Adjustment in CARS is done at a later stage and consequently the process starts
in step 2).
2. The Collector/ Pre-Legal Analyst or IGF Special Handling Analyst prepares the
request for obtaining the approval, which is necessary according delegated clip
level, through the Adjustment Approval Tool (AAT) which is a workflow notes
database to support the Write-Off approval process. This must contain:
Due to the sensitive nature of the transactions, special attention is needed

to ensure the auditability of any write-off including:
 Write-off authorization
 Supporting documentation including:
 Description of the item(s) being written off
 Reason for processing the write- off transaction

 CDMS log with summary of actions taken to resolve the item prior to
write off.
 COD flagging request in JIRA/ Update of Black List proof for all bad debt
cases, see exceptions below
 In case of write off requests:
- In countries where the AR Pre-Legal Analyst role is separated from the AR
Collector one
- The write off requester is the AR Collector
It is required to document the AR Pre-Legal Analyst position about the write off
request. This requirement is only mandatory for write off cases above 5K$
 Related correspondence and other pertinent documentation (i.e. invoice
letters, etc.)
 The name, title and signature of the person preparing the file, and the
date prepared this information is captured by the AAT tool directly
 The name, title and signature of the person approving the file, and the
date approved –, this information is captured by the AAT tool directly
 In case of write off performed in the last six months an explanation for
new Write Off request is needed (this check is only valid for countries
where write off is performed in CARS through "w" adjustment and
therefore CP screen shows the account’s write off historic record). This
check is not needed for write off cases in accounts under Suspense
status.
3. Once inserted, the request is submitted for approval within the AAT –
a. If the request is approved inside the tool, the initiated Adjustment in CARS
is validated against the approval package by the Squad Leader (or Iteration
Manager, or delegate).
For write-offs initiated by IGF Special Handling Analyst, the following additional
steps have to be performed:
• The Squad Leader (or Iteration Manager, or delegate) sends the link of the write-
off to the responsible Cash Administrator
• The Cash Administrator creates the Write Off Adjustment in CARS and informs the
Squad Leader (or Iteration Manager, or delegate) about the created Adj. Number
and CARS User ID the Squad Leader (or Iteration Manager, or delegate) approves
the write-off adjustment in CARS and in AAT - To link the approval with the
adjustment, the Squad Leader (or Iteration Manager, or delegate) will enter the
adjustment documentation in the AAT package previous to approve the AAT
request.
• If all approvals have been correctly obtained and the adjustment is matching the
request, the corresponding adjustment is approved in CARS, which results in
processing the write-off in the system. Following the approval the corresponding
Initiator is notified.
i. If any mismatch is detected, the adjustments needs to be rejected in
CARS and the responsible Initiator must be notified.
b. If the request is not approved inside the tool

i. In case the rejection is based only on missing information, the

initiator has to create a new request inside the AAT, including the
additional information as required.
ii. In case the rejection is based on business reasons, the adjustment
has to be deleted in CARS by the Initiator/ involved Cash
Administrator for write-offs initiated by an IGF Special Handling
Analyst upon notification
Write-off concessions for Trade cases are not allowed and should instead go through
the relevant IOT concession process. The concession process is owned by Finance,
and is therefore outside AR responsibility. IOT CFO should be involved for process
guidelines as concession is a different process and/or management system than
Claims/Trade Write-off. No dedicated team is handling concessions in AR nor Claims,
these are managed within the country by brands.
A concession may differ from a claim in that it covers situations where a formal written
request has not been received. A "concession" is a deviation to an approved contract
price or its terms and conditions. A concession can take different forms, including an
agreement to reduce future charges for existing services or to issue credits for services
already, or not yet, rendered. For additional information, please refer to AP09 and INT
04-02
There are several situations which could give rise to a concession, i.e.:
• A deviation to an approved contract price or its terms and conditions where IBM
concedes on either not billing, providing credit or free service.
• Resolution of an issue or potential issue or used in the interest of preserving
future business relationships.
• IBM concedes elements of contracted Revenue/GP which is given away during a
Renegotiation and/or "Give to Get" scenario where IBM gets something back in
return - i.e. as additional years contracted service in return for reduced
price/scope in the current contract.
From AR perspective, bad debt Write Off require the COD flagging request in JIRA or
Black List updating. Writing off credit notes or cash does not require COD or blacklist
flagging. Exceptionally, AR Country managers or Squad Leader can decide to do not put
a COD flag for a customer when a bad debt WO is performed on its account. This decision
needs to be documented in the WO package (e.g.: a comment from AR country manager
or Squad Leader: all the collection activities have been exhausted and as for the safety of the business
no COD must be reported or a comment in the Blacklist /COD flagging section confirming that SL or AR
country manager is in agreement). In this scenario, WO reason code to be selected is B (except
for countries with specific write off reason codes due to tax requirements).
Further important Guideline: Where Debt is factored, the write-off decision and
approval procedure must include the factor.

Write-Off Codes
CARS requires to add in any Write-Off adjustment a write-off code.
This write off code can be used for reporting purposes. Definitions of the write off codes
are as follows (excluding France, Italy, Nordics, South-Africa):
A. Arising from a customer dispute where IBM did not fulfill its contractual obligations.
B. In the interest of business relationships where IBM has fulfilled its contractual
obligations.
C. Customer financially unable to pay.
D. For payments or costs of alternative services which are rendered in settlement of

contractual liquidated damages.
Y. Only for write offs performed by Write Off Robot (over 90 remaining balance on invoices
<100 USD)
Z. Only for write offs performed by Write Off Robot (over 90 invoices >100 USD)
Some countries might have additional write-off reason codes. Other countries might be excluded from the
usage of above reason codes and have their own WO reason codes due to tax requirements. For more
information see Appendix
You can find a link to the write off reason codes for all EMEA in CARS in below link :
https://ibm.box.com/s/m71i60wws2woqi7r2q9vr8igb7cnnjx7
Write off robot for low value items:

In an effort to improve productivity and allow to focus AR activities on more high-value
receivables, AR is not required to take active collection action on invoices less than US
$35.
As required by law, the customer will continue to receive the invoice and may ask
questions, dispute, or pay the invoice. However, no collection activity will be required from
our A/R teams. If the invoice is not settled within 90 days, it will be written off automatically
by a system robot. In addition, all partially paid Invoices with a remaining balance below
$ 100 (with no further adjustments performed on the AR item), will be also automatically
written off after 90 days.
The following situations are outside the scope of the initiative, and will be excluded from
the report criteria:
Formatted: Indent: Left: 0 cm, First line: 0 cm

1. Invoices in dispute
2. Account or invoice(s) referred to OCA, or where collection effort is not being
performed by IBM
3. Account referred to Legal

4. Credit in process: in some countries this may be used to simply indicate that an
invoice is to be credited, but it is also used in some countries to indicate a balance
that is to remain open on the account until a Withholding Tax certificate is received
5. Direct Debit: where invoice is either manually included for DD or is included in next
CARS batch call-off
6. Factoring cases, either internal or external
The write offs performed by the robot can be identified in CARS IW: For these adjustments
there are two write off reason codes enabled in CARS: reason code 'Z' with following text
'As per AR collection policy, items under 35 USD not paid before 89 days are written off
automatically' and reason code ‘Y’ with following text ‘As per AR collection policy, items
<35 are written off automatically after 90 days of inactivity’.
Unallocated Cash and Credit note write off
In case that the collector would exhaust the contact attempts with the customer to clarify an
unapplied cash item (UAC) or credit note, a Write Off will be requested (no Cash on
Delivery/Black List flagging is required for this write off request):
At least 2 contact attempts should take place with at minimum of 5 days between them. These
actions have to be complemented with a final dunning letter to be sent to the customer asking for
bank details for a refund. This letter should also explain that in case of no reply from the
customer´s side within 10 days, the payment record will be written off. Acknowledgment of receipt
will be used if it is a country standard practice.
Note: A template of this dunning letter can be found in the Common Process Appendix document
An UAC/credit note write off follows the standard Write Off process explained in section. Therefore
the Write Off approvers will analyse the request and might require any additional action to
complement these minimum requirements.
Responsibilities / Ownership
AR Write-off authorization is under the responsibility of the appropriate Country Chief Financial
Officer (CFO) or HQ Accounting Director. Subordinate managers may have delegated write-off
authority as documented in either corporate, geography or country instructions.
For this purpose Common Europe & MEA Write-Off delegation matrices have been established
as outlined in Appendix D (implemented accordingly in the AAT).
All write-offs must be approved within the above authority.
1. Account Receivable
Preparation and submission of Write-Off requests is the responsibility of the AR Collector,
the AR Pre-Legal Analyst or the IGF Special Handling Analyst. The processing and

record-keeping (which is actually done within the AAT) of the approved Write-Off is in the
responsibility of the AR Cash Administrator.
2. Accounting
The accounting department processing the write-off is not responsible for the justification
and documentation requirements described above unless they directly own the activity
being written off. They are otherwise responsible for:
 The verification of the approval signatures
 The verification of concurrence by the process owner (that the management team
responsible for the activity has in fact agreed to the write-off).
 The timely recording of the transaction in IBM books
 Accessibility of documentation for audit purposes (internal/external)
 Archiving according to standards
 Compliance testing on adherence to documented procedures
Measurements
Documented copies of Write-Offs must be maintained in line with IBM’s WW Records

Retention Management Plan, and longer if required by country legal regulations. This
retention is done inside the AAT tool.
Further Guidelines:
If AAT tool is not available for a significative period of time, the process as outlined above
has to be followed accordingly, storing the mandatory documentation and obtaining the
necessary approvals by mail.
Specifics for AR Write Off Procedure for Customer Financing
The Customer Financing AR management for the majority of the countries in Europe is
handled by Q2C organization.
Q2C will handle the normal collection process. If a point is reached where the Q2C
organization believes there is a need to write off the AR then the following actions will
happen.
For all write-offs initiated by Q2C (cases under the responsibility of IGF Special Handling
Group will be submitted in the AAT directly by the Special handling Analyst -, Q2C will
take responsibility to put together a package which will give all relevant supporting detail
for the write off and submit via the AAT according the above outlined process. All
packages to contain a completed write off template. Package must also contain any other
necessary documentation to support the write off decision as determined by the Q2C
contact.

Once approval is received within the AAT, the Q2C contact will ensure the write off is
approved within CARS and all relevant approval documentation is held on file for audit
purposes.
If a write off is processed by Q2C accidentally or a write off is not processed but should
have been then the Accounting team will accrue the correction in the ledger but only when
confirmation that the case will be corrected during the following month is provided by the
local Q2C contact.
Write Off approval matrices (Trade) can be found in Appendix D.
Specifics for AR Write Off Procedure for External factored debt
Before writing off any debt that was externally factored, a request for approval must be
sent to Treasury Operations. The reason for the write off must be mentioned in the
approval request.
Global CF QMX:
Further information can be found in the following QMX document:
Adjustment Approval Tool (AAT) - Refunds and Write-offs (STS-O-0991)
6. Application Architecture
6.1. CARS RO Architecture

The Accounts Receivable environment is supported by the architecture shown in the picture
below:

In case that CARS or any other AR system would not be available it is expected that the Crisis
Management Team (CMT) for the affected AR Location will interlock with BT&IT to highlight and
track the situation until resolution.
The CMTs detected this kind of contingency have to inform to the AR Europe team to allow
evaluating the situation and providing guidance about how to operate until that/those system/s
will be recovered.
6.2. Invoicing
The Europe Common Invoicing Process is described in the Europe Common Invoicing Process
Document which is posted in the Q2C library as well as on the IBM intranet.
CARS requires to receive invoices in a pre-defined forma, the invoicing input file to CARS for
accounts receivable and interface to FDW for revenue recognition/accounting is originate from
the same invoice transaction.
For further information on the Invoicing systems, as well as further guidelines on Advances
Invoicing and compliance invoices, please see the Europe Common Invoicing Process:
http://d01db034.pok.ibm.com/q_dir/qmx/aca/qm8pl.nsf/procnum/CF-P-2696
Important Invoicing guidance lines which directly impact in the AR Process:
The following guidance lines were announced by Invoicing in June 2012 which directly requires
Q2C AR involvement:

Advanced Invoicing:
Advanced Invoicing is considered Invoicing before the originally agreed trigger date (billing
milestone) as mentioned in the contract.
This exceptional request should be supported by :

- a written client payment commitment to settle the advance invoice by a given date.
- the reasons behind the request to facilitate evaluation of options.
In case a complete request is received the following process should be executed by the Contract
Management Team.
1. Q2C AR validation:
Any advance invoice request is to be reviewed by the Country AR manager and is required to
meet the following conditions:
• The client cannot accept an alternative solution, such as a client accounting

adjustment/advanced booking, a pro-forma invoice, etc., Case is justified.
• The client payment behavior is deemed to be acceptable in the experience of the
responsible Squad Lead. ie. Payment is likely.
• DSO Impact is determined and the following approvals are met.
I. Country AR manager evaluates the case as justified and the client payment
commitment firms that the settlement will be completed by the end of the last working day
of the ongoing quarter - > no DSO impact on current quarter - > AR ctry manager can
approve
II. Country AR manager evaluates the case as justified and the client payment
commitment confirms that the settlement will be completed beyond the current quarter - >
DSO impact on current quarter - > additional Europe AR Manager approval is
required.
In case the Country AR manager and/or Europe AR Manager do not approve the request, the
advanced invoice can only be issued once the payment is received.
2. Cancellation option for unpaid Advance Invoice

If client does not fulfill its payment commitment, AR must request the Advance Invoice
cancellation through a credit note to the administrator/team originating the invoice. It is
recommended to inform the client upfront of the consequence of non-payment by the committed
date.
This additional guidance is not changing existing country rules/requirements to be followed for
invoices in advance (eg: Tax manager and/or CFO approval might be required, TAX treatments,
etc)
Compliance Invoices:
Compliance invoices are invoices where IBM, with a valid legal claim, wishes to invoice a
customer who refuses to acknowledge that claim to invoice. Typically these invoices are to
support a client dispute or negotiation and therefore are usually not or just partially paid.

Even though these invoices are rare due to the their impact on DSO, specially for high revenue
cases 3 approvals are required Geo/IOT CFO, Geo/IOT Sales GM, and Legal..
In addition to these approvals now the Q2C AR Geo Executive needs to provide approval.
The approval side of such invoices are managed by the representative from a so called
compliance team.
Before raising any compliance invoice the Contract Management Team should ask if the request
is reviewed by the Country AR manager to agree that all the required approvals are in place.
After raising a compliance invoice Contract Management must notify accounting so that the
appropriate action can be taken in the Financial Statements. Since collection is not reasonably
assured revenue in the ledger must be reversed, or proper actions must be taken in order for the
revenue not to flow through the ledgers.
Furthermore Contract Management should continue to notify accounting on a monthly basis, on

the status of any compliance invoice for proper determination of accounting treatment, until such
time as the customer accepts the claim or pays the compliance invoice and cash is received.
7. Reporting and Data Management

Description
Reporting and Data Management of the AR Process is split into 3 separate areas:
 Corporate and Europe reporting requirements.

 Process control and reconciliation reporting.
 Operational & Management reporting requirements.
1. Corporate and Europe Reporting

In order to meet Corporate and Europe Accounts Receivable reporting requirements, a suite of
standard reports have been designed for use by countries and EHQ. These reports support the
majority of the identified and agreed requirements in place at the time of writing this process,
and therefore should not require addition or modification. Where the reports can be directly and
solely sourced from the CARS RO IW, Development and maintenance of these reports is the
responsibility of the Central User Group.
2. Process control and reconciliation

These reports are available from CARS via RMDS for use in countries as the means of control
and reconciliation of CARS against the feeder applications and functions. They are maintained
by the CARS ADM Centre and UKMVS, and have been reviewed and approved by the WW AR
Process Leader.
3. Operational & Management reporting requirements

These reports have been designed as the template to support country operational groups
managing and executing the AR Process, in accordance with this document, and, in addition, to
provide management reports to other functions supporting the AR process through incentives

and the resolution of aged and disputed debt, as part of AR segmentation . They reflect and
support each sub-process of the template. Where the reports can be directly and solely sourced
from the CARS RO IW, development, maintenance and the production will be the responsibility
of the Central User Group. Where data cannot be sourced from CARS, responsibility for
development, maintenance and production is with the country.
Responsibilities
Country responsibilities
- To ensure Europe common data is passed into CARS through the Billing Files and Customer
Record interfaces wherever possible. This should include, for example, the common Brand /
Sector values to be included in the Customer Record interface.
- To prepare/utilize all the Europe common AR reporting as described in this process template. In
practice this means that countries should use the common reports prepared centrally by Europe
where the data is sourced from CARS, and produce the remaining reports directly from local
sources.
AR Central User IW Support

- To prepare and maintain queries and reports based upon this process template for countries
wherever the data can be sourced directly from CARS RO or CDMS. To make all prepared reports
available to countries through a notes database.
Europe AR Operations
- To prepare and maintain queries and reports based upon this process template for countries
from various sources. To make all prepared reports available to countries and Brands through the
Web (WW AR Reporting tool ).
Europe and MEA AR Process SME

- To review any proposed additional country reporting requirements to determine if they should
be added to the Template.
- To own all the common Europe reporting needs and requirements.
- To act as User of Record for all deliverables.
- To ensure that the deliverables meet the requirements for all such reporting.
7.1. Corporate and Europe Reporting

A) CHQ Reports:
Following are detailed the standard reports required by CHQ (Corporate Headquarters) to provide
specific A/R information. This list includes all A/R related reports, sometimes linked to
upstream/downstream sub processes like Credit Management or Accounting. However, only pure
operational AR requirements are described in detail in this document.
B) Billing and Receivable Efficiency Measurements:

Description
Data provided by Finance for monthly and quarterly CHQ reviews:
a) Measurements
a1- Quarter DSO revenue (current 3 months revenue, eg for June it’s June, May, April)
a2- 3 month prior DSO revenue (e.g. for June it’s May, April, March)
a3- Core Unbilled A/R (Major 107 minor 148 to 160)
a4- Core A/R Due Over 30 days (Major 107 - 0110, 0160, 2110, 2160)
a5- Core A/R Not Yet Due (from Major 107 minor 120/2120)
b) Ratios:
b1- DSO (Europe and PSG, IMD, SSD, Lotus split)
b2- Delinquency to Revenue (Trade A/R due over 30days as a % of prior 3 months revenue)
b3- Unbilled to Revenue (Unbilled A/R as a % of current 3 months revenue)
b4- Customer Financing DBO (Customer Financing A/R as % of current 3 months billings) -
Delinquency to Billing (Customer Financing A/R over 30 days as a % of prior 3 months billings)
C) Top Europe Aged Cases:
Description
Quarterly report to be submitted to CHQ Finance by EHQ, listing the top Aged cases in the
geography with detailed information. (Followed up by monthly update).
 Top 5 Accounts Over 90 days Trade A/R (AP AR)
 Top 5 Accounts Over 90 days Customer Financing A/R (AP AR)
 Four oldest Outstanding Invoices (excluding Suspense and greater than 1000 $)
Report Requirements:
a) Top Accounts: Customer Name, Country, Total A/R Outstanding, Overdue, Over 90, Over
180 at quarter end.
In case of Customer Financing cases NIB (net investment balance) is requested. This is the
portfolio of AR not yet due less unearned income plus RV.
Every case has to be explained with a management style summary (revenue type, product,
reason the invoice/AR is outstanding, person/group responsible for resolution, estimated
resolution date).
To fulfill CHQ requirements, IOT’s/ IMT’s requires from countries a quarterly Country Top Aged
Cases Report from where above cases will be selected, as well as a monthly update and follow-
up on previous cases.
Country Report Requirements:
a) - Top 10 accounts Over 90, Top 10 accounts Over 180, Top 10 accounts Over 365 - Trade
A/R
- Top 10 accounts Over 90, Top 10 accounts Over 180, Top 10 accounts Over365 - Customer
Financing A/R

- Top 10 accounts Over 90, Top 10 accounts Over 180, Top 10 accounts Over 365 days -
Global Services (segmented by requested sub-segment)
Customer Name, Industry, Revenue Type, Dispute flag and Code, Total AR Outstanding, Total
Overdue, Over 90, Over 180, Over 365, Estimated Resolution Date and Remarks. Customer
Financing Accounts should also show Net Investment Balance (NIB)
D) Accounting Reports
Description
Reports related to A/R to be provided by Country Accounting function to CHQ Finance.
Report Requirements
a) Monthly Ageing Report;
Trade, Customer Financing, Commercial Financing ageing profile at country level with
breakdown by category (report 7-320);
Current, Overdue 1-30 days, 31-60, 61-90, 91-180, >6 months, <1year, >1year ,
Total Suspense, coverage %
b) Annual Suspense Netting (Annual report number 7-310)
c) Quarterly Reserves reporting. . To be provided;

a- prior to quarter end
b- on 5th working day when data is final
d) Quarterly Internal factoring Reserves report
E) Europe Reports:
Added to the compulsory Corporate reports, countries must provide IOT’s IMT’s with a
complementary monthly submission of data. Europe requirements have two objectives;
1. Ensure basic information for managing A/R is obtained and handled in countries to
achieve A/R targets, and
2. Provide IOT’s/ IMT’s with consolidated information for tracking, coordinating and
managing activities.
F) Planning and Tracking of AR Collection contribution to DSO:
Description
To support regular AR Collection planning and tracking activities reports are retrieved from
CARS & CDMS IW / Engage AR. The regular planning and tracking activities are linked to WW
AR metrics. (see 5.5.1)
Planning supports quarterly Aging (Delinquent / Aged 90 Forecasts) in line with the quarterly
DSO targets released by EMEA Treasury.

A/R components of the DSO measurement are split as follows:

- Billed and Aged
- Not Yet Billed
- Unbilled
- Suspense
* Subsidiaries (outside CARS) A/R is included in each above items
7.2. Reconciliation Reports and Requirements
A) Description
This section objective is to list the system reconciliation and controls performed by the BT&IT
organization in order to ensure the integrity of AR systems (CARS and CDMS / Engage AR) and
its files and databases.
Summary of Daily checks performed by CARS/CDMS BHD / Engage AR
The checks are performed on a daily basis indicating any errors or variances. The purpose of all
these controls is the proper function of the systems, to detect any mismatches and to ensure
consistency. The checks are based on reports run by robot or agent.
1) System availability
To ensure that the CARS system is fully available for use.
Check performed at clone level.
Any errors are escalated to 3rd level support.
2) CDMS Log Agent checks

To ensure CDMS is working correctly. Verifies CDMS DBs have been updated by walking through
each Logging DB.
Check performed at clone level
3) RMDS Reports Variance

To ensure that the country balances have no variances from the amount sent to and received by
CARS.
* Ensure that the closing balance of the previous day is equal to today's opening balance and
check that the variance is zero. Based on RMDS report 001.
* To check that the CARS IW has correctly loaded after the batch run ensuring data in CARS
matches data in IW and RMDS.
* To detect system errors. Based on robot run against data from RMDS report 130
Check performed at country level.
4) Rejected Report
To detect rejected billings and payments. Based on robot run against data from RMDS report 003.
Any errors are followed up by the Key User team.

5) Accounting discrepancy 99 reports

Verifies that Accounting objects have been updated correctly, detecting miscodes.
Any errors are notified to ARAC.
6) Credit card Status report (CCSTAT)

* FCO requests with no response from PS (status 2) for more than 1 working day.
* Confirmed FCO requests waiting for a payment (status 3) more than 7 working days.
Any errors are followed up by the Key User team. Items are followed up with the Payment System
Team (Payment Systems Booking Department PSBOOK/Denmark/IBM) and in the case of
missing/duplicated transmittals, these are followed up with the Key User team and the CoC.
7) Billing Records written

To identify when a billing file fails to fully process.
Check performed at clone level.
8) X-flags MQMessages for dispute information update CDMS

Reconciliation of open disputes in CARS and CDMS.
Any errors are followed up by the Key User team. Any errors are followed up with the CoC and
CDMS ADM.
9) RMDS Reconciliation – CARS System to CARS IW

Reconciles CARS itself with its IW instance, by comparing today's 2 files with the RMDS report
file generated earlier. Related to control 1
10) CDMS Reconciliation

Reconciliation of open items in CARS and CDMS.
B) RMDS reports:
To support the controls listed above and complement operational controls and measurements the
following reports are available.
Reports Review Frequency

Daily
001 - Daily Balancing
002 - Transmittal Control
002S - Transmittal Control - Payment Summary
002S - Transmittal Control - Adjustment Summary
003 - Rejected Transmittals
003A - Rejected Transmittals - Automatic Cash

004R - Rejected Installation date Records

004S - Ignored Installation date Records
004U - Updated Installation date Records
005 - Transaction Control
018 - Changed Due Date Report
019 - Calculated Late Payment Charge (LPC2 & no approval)
028A - LPC Approval Status (Approvals) (LPC2 + approval set)
028M -LPC Approval Status (Modifications)
028R - LPC Approval Status (Rejections)
028T - LPC Statistics Report
028W - LPC Approval Status (Waiting for Approval)
030 - Open balance by division
037 - G/L Transaction Log
041I - CredCard FCO Responses Invalid
041V - CredCard FCO Responses Valid
082 - CARS - Interest Trigger Interface
092 - Split Transmittals
093 - Automatic Payment ReAllocation
128 - Interest Trigger
130 - System Control User Messages
Weekly Reports
110 - Unidentified Payments
116 - Receivership / Liquidations
118 - Future-dated cheques, by deposit date
120 - Collection priority
Monthly Reports (either at month start or month end)
006 - Transaction Log by transmittal
007 - Transaction Log by Customer
008 - General ledger reconciliation
009 - G/L Adjustment Summary
010 - Invoice Reconciliation Cross-ref
011 - Regular / Installment - Aged Trial Balance - By Company
012 - Regular / Installment - Aged Trial Balance - By Division
013 - Small Balance Write-Offs
014 - LPC/EPD Report for Traditional Customers
015 - LPC Report for Channel Customers
016 - LPC/EPD report for Quarterly Billings
020 - Payment Methods Details
021 - Payment Methods Total report by Customer
022 - Payment Methods Total report
100 - Payment Trend
101A - Payment Trend Report

101B - PayTrend Report - Monthly rolling data

109 - Suspense Accounts - Legal / OCA
111 - Credit Balances
113 - Proforma Invoices
114 - Legal & OCA Referrals, Accounting treatment W & Blank
119 - Service Agreement Summary
121 - Unapplied Cash
These reports can be directly accessed by country users in RMDS via VAMP screen.
A data base tool is in place to ensure the storage of the reports which are mandatory for any of
the system integrity and/or operational controls in place. This tool is called: “RMDS data base
tool”
Reports are listed under 3 timing schedules; Daily, Weekly, or Monthly
Explicit detail concerning use and contents of each report listed below is contained in the CARS
'Report Descriptions and Batch User Message‘ guide which can be found in the “EP & MEA CARS
Run Once CUG” Team Room.
Details of the content of each such report are available in the CARS Report Descriptions Guide.
Details of access to the utility application RMDS (from which these reports, by country, are
available) are to be found in the 'Login Guide' section, then 'Production')
7.3. Operational & Management Reports

Description:
The table attached below lists the different sources (Information Warehouse databases and the
Web – Global Tables) where AR information is available.
Operational reports should complement Europe and Corporate reports providing necessary
information and analysis to ensure Accounts Receivable is managed in a controlled and
successful manner. In addition they can be used to prepare any A/R presentation to
Management. The goal is to provide countries with these reports automatically, reducing to the
minimum the need for ad-hoc queries.
The IW queries will be developed and maintained by the Europe Information Management team
(called Reporting Center) , and will be subject to ongoing review and update where changes are
agreed to meet Europe operational and functional demands.
WW AR Reporting Tool queries are maintained by the Europe Focal Point on behalf of Europe AR
Operations Leader.

Management reports to be supplied on a regular basis to other functions will be agreed at

Europe level to ensure consistency across countries.
Source Purpose
Global tables and WW AR Management Reporting (Cognos based )

Reporting Tool
CDMS Operational Reporting and data details (Notes based )
CARS & CDMS IW Operation Procedural Standard & Ad Hoc Query (QMF)
RMDS CARS Predefined reports (MVS)
Appendices
Appendices are published in a separate document to allow a more flexible review management
and therefore keep them updated at all times.
This complementary document is named “Common EP & MEA A/R Process Appendices” and will
be jointly stored with the Common EP & MEA AR Process.

Common EP&MEA Accounts Receivable Process V6.0 July PDF

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Common EP&MEA Accounts Receivable Process V6.0 July PDF

Caricato da

Copyright:

Formati disponibili

Common EP & MEA Accounts

Revision Number 6.0

Document Control Section / History

Ownership & Approvers:

Role Name Title

Document Thorsten Dahlke AR Market Leader MEA

Document Joan A Nelson Director Global STS A/R Transformation

IBM Confidential Page 2 of 152

Revision # Revision date Summary of Changes

IBM Confidential Page 3 of 152

V5.2 June 2017 - Contacts in reviewers list updated.

IBM Confidential Page 4 of 152

V5 March 2016 - Updated Reviewer list

IBM Confidential Page 5 of 152

4.8 September 2013 - Renamed all CF to STS (CF)

IBM Confidential Page 6 of 152

4.7 July 2012 0. Reviewer list updated

IBM Confidential Page 7 of 152

IBM Confidential Page 8 of 152

4.4 October 2008 • Updated Refund Process

Validity of this document:

IBM Confidential Page 9 of 152

1. Introduction and Purpose ...................................................................................................... 12

IBM Confidential Page 10 of 152

5.3.9. Dispute Measurements ................................................... Error! Bookmark not defined.

IBM Confidential Page 11 of 152

1. Introduction and Purpose

The document should enable a strategy of ‘a common AR process supported by Run-Once

IBM Confidential Page 12 of 152

2. Account Receivable Process Definition and Objectives

The process includes:

• Planning & Controls

IBM Confidential Page 13 of 152

Accounts Receivable Process

Planning & Collection Dispute Cash Reporting

Planning & Collection Dispute Mgmt

Cash Reporting & Data Mgmt

Finance (linkage with

IBM Confidential Page 14 of 152

- Cash Allocation - AR Accounting - Corporate and EP & MEA reporting

The AR Process does not include:

3. Accounts Receivable Accounting, which is directly owned by Accounting.

2.2. Accounts Receivable Environment

IBM Confidential Page 15 of 152

Ledger Customer User

2.4. Deviation approval request

The following approval path must be completed:

1. First approver: Country A/R Manager/Squad Leader

IBM Confidential Page 16 of 152

3. IBM World Wide Payment Terms (WW PT’s)

Complementing the WWPT’s, EMEA Treasury announces complementary guidance/approval

4. Accounts Receivable Roles and Responsibilities

Roles and Responsibilities

The 9 AR Role types, and their responsibilities, are:

AR Low Touch Collector is responsible for:

IBM Confidential Page 17 of 152

• Production of Customer Statements of Account and Customer Account reconciliations on

AR Collector, responsible for:

AR Pre-Legal Analyst responsible for:

AR & Collection Planning Specialist responsible for:

IBM Confidential Page 18 of 152

Process SME for AR/invoicing and Kaizen squad