Professional Documents
Culture Documents
Receivable Process
Revision History:
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.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
Distribution: Through Finance & Q2C to any Europe & MEA personnel involved in the
Accounts Receivable Process.
Contents
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.
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.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 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:
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:
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
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.
“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.
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
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
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 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
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):
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)
• Raising Adjustments (as per the Common Adjustment Matrix)
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).
• 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)
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”.
• Collection
• Dispute Management
• Cash Administration
• Pre-Legal Administration
• AR Planning
• AR Controls
Each activity is described in the following sections, and further broken down to specific
procedures.
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.
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.
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
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.
Linkages
This activity links to all other AR process activities, and specifically impacts overall DSO,
Collection Profile and aged debt performance.
Steps/Activities
A) Performance planning
B) Execution
C) Performance monitoring
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).
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).
1.1 The applicable invoices suitable for SDD process and in line with the defined criteria are
indentified
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.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
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
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)
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):
https://d01db034.pok.ibm.com/q_dir/qmx/aca/qm8pl.nsf/procnum/STS-O-0984?OpenDocument
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.
• 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)
- 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.
• collection coverage
Measurements
• 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)
https://d01db034.pok.ibm.com/q_dir/qmx/aca/qm8pl.nsf/procnum/STS-O-0976?OpenDocument
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.
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.
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.
Linkages
Steps/Activities
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.
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
Steps/Activities
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.
• 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.
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.
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.
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
Steps
The production and dispatch to Customers of monthly Statements of Account, and ad hoc
Customer Account Reconciliation reports.
Linkages
• Customer Record.
• Collection activities
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.
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
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
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
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
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
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:
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
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.
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
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.
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.
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.
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.
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.
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.
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.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.
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.
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.
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.
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.
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.
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.
Responsibilities
LPF control and production are the responsibility of the AR LPF Administrator role, with assistance
from the Invoicing Operations function.
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.
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.
Linkages
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.
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)
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
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)
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
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)
Responsibilities
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
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
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.
IGF
Receive invoice in
receive invoice in
CARS
IRFS
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:
Further information can be found in the following QMX document.
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
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
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).
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.
‘’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.’’
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.
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.
- 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.
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
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.
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.
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.
• 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 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.
• 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).
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.
• 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.
• 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.
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
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:
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.
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.
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.
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
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
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.
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.
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.
• Cash Application
• Unapplied Cash
• Alternative Payment Methods
• Cash Control
• Direct Debits
• Multi-Company
• A/R Accounting
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
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.
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.
Receive Payment
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, 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:
Further information can be found in the following QMX document.
Withholding tax process:
https://d01db034.pok.ibm.com/q_dir/qmx/aca/qm8pl.nsf/procnum/CF-O-0909?OpenDocument
B. Partial- / Underpayment
Cash Administration Subprocess Cash Application
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
C. Double Payment
Cash
Application
Identify apparent
double payment
Check against
recurring invoicing
activity (incorrect
reference on
remittance advice)
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
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
Notify Collector
accordingly (no
N/A
matter if balance
positive or
negative) to clarify
situation with the
customer
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)
https://d01db034.pok.ibm.com/q_dir/qmx/aca/qm8pl.nsf/procnum/STS-D-2229?OpenDocument
E. Overpayments
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
F. Incorrect Payee
Cash
Application
Identify incorrect
payee
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
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
Further Guidelines
Global CF QMX:
Further information can be found in the following QMX document.
Multi-Company Cash Management DLP (STS-D-2076)):
https://d01db034.pok.ibm.com/q_dir/qmx/aca/qm8pl.nsf/procnum/STS-D-2076?OpenDocument
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
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
Cash
Application
Identify a Multi
Currency Scenario
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
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).
Linkage
Steps
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).
- 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.
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.
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.
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.
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
https://d01db034.pok.ibm.com/q_dir/qmx/aca/qm8pl.nsf/procnum/STS-D-2555?OpenDocument
STS-D-2549 AR_Global_Credit Card Chargeback
https://d01db034.pok.ibm.com/q_dir/qmx/aca/qm8pl.nsf/procnum/STS-D-2549?OpenDocument
STS-D-2521 AR_Global_Credit Card Exception Process
https://d01db034.pok.ibm.com/q_dir/qmx/aca/qm8pl.nsf/procnum/STS-D-2521?OpenDocument
STS-D-2517 AR_Global_Credit Card Incident Reporting
https://d01db034.pok.ibm.com/q_dir/qmx/aca/qm8pl.nsf/procnum/STS-D-2517?OpenDocument
STS-D-2518 AR_Global_Credit Card Pending Payment URL
https://d01db034.pok.ibm.com/q_dir/qmx/aca/qm8pl.nsf/procnum/STS-D-2518?OpenDocument
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
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).
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.
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
Steps
• 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:
Further information can be found in the following QMX document.
Handle Promissory Notes DLP (STS-D-2077):
https://d01db034.pok.ibm.com/q_dir/qmx/aca/qm8pl.nsf/procnum/STS-D-2077?OpenDocument
The following control activities comprise the required elements for good Cash Control:
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.
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.
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;
• 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 amount per bank account per direct debit type (zero value is recommended)
• 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
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).
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:
Further information can be found in the following QMX document.
Direct Debit Management non SEPA DLP (STS-D-2075)
https://d01db034.pok.ibm.com/q_dir/qmx/aca/qm8pl.nsf/procnum/STS-D-2075?OpenDocument
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)
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.
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:
Further information can be found in the following QMX document.
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.
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.
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:
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.
This means that the Delinquent Management process should always be the effective process for
reaching a decision as part of the Pre-Legal review.
• 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
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 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.
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.
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:
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:
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.
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
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
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.
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
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).
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’.
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.
STT functions as a repository tool for suspense accounts. The AR STT has been deployed in EP
& MEA
Reports on Pre-Legal situations must be prepared monthly for the country Credit Committee, and
to ensure reconciliation for accounts subject to suspense accounting.
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.
- 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.
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.
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.
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
https://d01db034.pok.ibm.com/q_dir/qmx/aca/qm8pl.nsf/procnum/STS-D-2438?OpenDocument
- Cash on Delivery (COD) and Black List DLP
https://d01db034.pok.ibm.com/q_dir/qmx/aca/qm8pl.nsf/procnum/STS-D-2445?OpenDocument
- Use of A/R Suspense Tracking Tool (STT) DLP
https://d01db034.pok.ibm.com/q_dir/qmx/aca/qm8pl.nsf/procnum/STS-D-2437?OpenDocument
5.6.5.5. AR Planning
Description
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.
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:
• 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.
Objective: Finish with a lower $ amount than assigned.
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.
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.
The AR Planning function includes the coordination and supervision of all agreed operational
reports requested to support the country/geography A/R organization performance.
There are additional, key requirements to link all the functions involved in AR Process together
during performance periods.
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.
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:
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:
Further information can be found in the following QMX document.
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.
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.
• 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.
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.
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.
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.1.5.7.1. Adjustments
Description
- Unapply invoice / credit note acc. mail from customer from 'date'
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.
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
Remittance
No information Yes
received?
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
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.
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)
https://d01db034.pok.ibm.com/q_dir/qmx/aca/qm8pl.nsf/procnum/STS-O-0991?OpenDocument
5.8.3.5.7.3. Write-offs
Description
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
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
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.
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
The following situations are outside the scope of the initiative, and will be excluded from
the report criteria:
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’.
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).
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
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.
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.
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)
https://d01db034.pok.ibm.com/q_dir/qmx/aca/qm8pl.nsf/procnum/STS-O-0991?OpenDocument
6. Application Architecture
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
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.
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:
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.
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.
Reporting and Data Management of the AR Process is split into 3 separate areas:
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.
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 ).
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.
Description
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)
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.
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 %
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.
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) 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.
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.
4) Rejected Report
To detect rejected billings and payments. Based on robot run against data from RMDS report 003.
Check performed at country level.
Any errors are followed up by the Key User team.
B) RMDS reports:
To support the controls listed above and complement operational controls and measurements the
following reports are available.
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”
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')
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.
Source Purpose
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.