Best Practices for Creating Customer Masters

When Customer Master records are maintained correctly in a mission-critical SAP production system, transacting with customers is easier, faster and less frustrating for the internal resource and the customer. Like the view from a mountain top on a clear day, downstream reporting used for granular overview of single customers all the way to overview of the entire enterprise is accurate and therefore actionable.

The following are simple best practices that have been adopted by successful CRM and ERP implementations enabling them to control Customer Master data and prevent issues from cascading as more organizations are rolled up into a single ERP system. Best practices prevent data stewards and data migration specialists from filling a production system with Customer Masters that are not suitable for transacting with customers and from causing downstream reporting to be unsuitable for running any organization.

Create a single Customer Master for every customer.

As an organization grows, so does the tendency to unnecessarily complicate its master data. Where the customer is already being transacted with through a single Customer Master, there is no need to create an additional Customer Master for divisional applications within the organization.

Standard SAP has the built-in capacity to enable divisional activities with a single Customer Master through Company Codes and Sales Orgs—activities like correspondence, sales, delivery and billing. Only when there is a legitimate business requirement such as a secondary address that must be used for business activities like shipping and billing should additional Customer Masters be created in the production system to represent a customer and these additional Customer Masters should be in account groups particular to the business activity for which they are created.

Do not create Ship-To’s or Bill-To’s that are identical to existing Customer Masters.

The only legitimate business requirement to create a Customer Master in a Ship-To or Bill-To account group that represents a customer who is already represented in the system by a Customer Master in a Sold-To account group is the requirement to interact with the customer at a different address. An existing Sold-To Customer Master should receive shipments and invoices on behalf of another Sold-To instead of creating new Ship-To and Bill-To Customer Masters.

Do not create Sold-To’s that are identical to existing Ship-To Customer Masters.

When the requirement to sell to an existing Customer Master that has previously only been used as a Ship-To for other customers, the natural maintenance activity is to change the account group of the existing Customer Master to a Sold-To using transaction XD07 instead of creating an identical Customer Master in the Sold-To account group. If, because of numbering ranges, converting the Customer Master to a Sold-To could cause confusion, then be sure to shift all of the existing partner functions from the Ship-To Customer Master to the Sold-To so that it can be sunset after all of the open transactional documents are settled.

Do not put two addresses in the address fields.

Two addresses in the address fields can only serve to confuse and delay correspondence and there is no legitimate business requirement to have two addresses in the address fields. No carrier can be relied upon to guess which address is the correct one for delivery.

Do not create a duplicate Customer Master for a post office box.

Where a customer has both a street address and a post office box address, SAP has built-in functionality to handle the street address in the address fields of the Customer Master and the post office box in other specialized fields so that, with the use of routing, the system can logically pick the appropriate address based on the business function being performed. The only legitimate business requirement for creating an additional Customer Master for a post office box is when a function like billing is to be directed to a post office box that is different from the customer’s post office box for normal correspondence.

Put the legal name of only one business entity in the Customer Master.

If there are two unique business entities operating from a single address then create two unique Customer Masters, one for each unique business entity. Putting two names in a Customer Master may seem like it adds clarity, but it only leads to confusion when transacting and communicating with the customer.

When a customer is “Doing Business As” or “DBA”, this implies that the customer has filed the appropriate fictitious name documents and that the legal process whereby a business is empowered to sign contracts and to open bank accounts has been completed. In this case, the organization is doing business with the customer that has been granted the power to do business with the fictitious name and not with both the parent and the DBA, so there is no reason to put a customer name on the first name line and then “DBA:” on the second name line.

When two businesses operate from the same address, do not put the name of one business and then “care of” another business name. By including the name of the only business being transacted with, it is still possible for correspondence, shipping and billing to be accomplished without the additional back office confusion caused by having two names in the Customer Master.

When a customer changes its name or is rebranded through acquisition, it is tempting to add “formerly” followed by the old name of the customer, but that temptation must be ignored. Either rename the old Customer Master with the new name or create a new Customer Master with the new name until the old Customer Master with the old name can be sunset.

Handle hierarchical customer structures with the Customer Hierarchy and not by including the name of the parent company in the Customer Master. There is no legitimate business requirement for putting “a division of” followed by a second business name in a Customer Master name field.

Do not put instructions in the name or address fields.

Sometimes the temptation to include a note in the name or address field with instructions like “Call Mary at 555-1212 so she can meet you at the back” is overpowering, but this note is then included in all correspondence to the customer from all internal divisions in the organization. SAP has built-in functionality that provides for the inclusion of notes specific not only to the division within the organization, but specific to the various documents produced by SAP so that a delivery document for a shipment sold by one Sales Org to the customer can have different instructions than a delivery document from another Sales Org.

Receptionists and mailroom clerks already know that invoices go to the accounts payable department, so there is no need to include “Attn: Accounts Payable”. Likewise, delivery drivers already know to deliver product to the loading dock so there is no reason to include “Attn: Deliveries”.

When possible, include granular delivery instructions in the Texts of the Customer Master specific to the Sales Organization transacting with the customer instead of putting things like “HVAC Division” or “Floor 2, 3rd Cubicle”. Putting such granular detail in the Customer Master Texts or in the Sales Order Texts obviates the need for a unique Ship-To or Bill-To Customer Master for every door, dock, floor, desk, department and person in an organization.

Do not put the name of the city, region or country in the name field.

Only when the name of the city, region or country is part of a business entity’s legal name should that information be included in the name field of a Customer Master. The ability to perform searches on the city, region and country fields during the creation of transactional documents obviates the need to include this information in the name of the Customer Master.

Do not make unique Customer Masters for each phone number.

When a customer has multiple internal resources reachable through different phone numbers, it is recommended to maintain these Contact Persons in a single Customer Master in the “Contact Persons” tab. There is no legitimate business requirement for creating two Customer Masters that are identical except for phone number.

Use actual street addresses instead of vague places.

“LINCOLN HWY AT COZZENS LN”, “RT 27 COZZENS LN” and “1800 NJ-27” are all the same address, but only one is a legitimate street address with a house number. Relying on delivery drivers and mail carries to know where streets intersect increases the risk of lost or returned deliveries and correspondence.

“4 miles south on I-10” may work for some situations, but “10802 US-10” will work just as well for those same situations and for all other delivery operations. Directions like “start at the delivery plant and drive 4 miles south on I-10” can be included in the delivery notes by adding them as texts specific to the Customer Master at the Sales Organization level instead of creating a Customer Master for every way of finding a customer’s physical location.

Include the customer’s name when creating Customer Masters.

An organization can sell, ship and invoice a Customer Master without the customer’s name, but it is recommended to include the name of the business entity in the name fields. There is no legitimate business requirement for leaving a customer’s name out of the Customer Master record.

Include the customer’s address when creating Customer Masters.

Shipping and corresponding with customers when their Customer Masters are created with no address is nearly impossible. If the Customer Master is meant to represent a general customer with a delivery address that changes for every Sales Order then try to note that in the address field or perhaps the Search Term 2 field instead of just leaving the address blank.

Include the city, region, postal code and country in the address.

Except for countries that do not use postal codes or regions, there is no legitimate business requirement to leave any of these fields blank. These values are essential to facilitate business operations include shipping, billing and other correspondence and ultimately impact downsteam reporting.

Put the City, Region, Postal Code and Country in the correct fields.

There is no legitimate business requirement to include the postal code, country or region in the city field, address field or name field. These values must be used to populate only the appropriate fields.

Even though deliveries can still be made without the fields being populated correctly, careless data entry makes downstream reporting and analysis particularly difficult. Searching for a Customer Master based on filters applied to these fields make transacting with the customer more difficult and can lead to the creation of duplicate Customer Masters.

Do not spell out the house number.

There is no legitimate business requirement to make deliveries to “Twenty Three Corporate Street” instead of “23 Corporate Street” and spelled out house numbers can confuse carriers. Ratifying a standard whereby house numbers are all numeric simplifies searches for customers during document creation and reduces the risk of creating duplicate Customer Masters.

Spell out the customer’s complete name when possible.

Very few business entities have names that are longer than 60 characters, so there is no reason that a Customer Master should have a name like “Meth Church” instead of “Methodist Church”. Unnecessarily abbreviating the name in a Customer Master makes searching for the customer while creating documents more difficult and increases the risk of creating duplicate Customer Masters.

Cleansing Customer Master records.

Occasionally, even the most professional of organizations can create Customer Masters without adhering to standard best practices. In these cases, the Customer Master records must be cleansed to regain control over the data and to optimize back office functions.

The XD02 transaction is used without risk to business continuity to correct the following problems with Customer Master records:

• Missing, misspelled or unnecessarily-abbreviated customer name
• Vague or missing street address
• Spelled-out house numbers
• Two customer names
• Two street addresses
• City, region, country or postal code in the wrong fields
• Post office box in the name field

The XD02 transaction can also be used without risk to business continuity to enrich Customer Masters with:

• Long texts with delivery instructions
• Long texts with billing instructions
• Additional contact details for customer’s internal resources

The XD07 transaction can be used without risk to business continuity to change the account group of a Customer Master that was created for divisional activities like delivery or billing but is to become an active Sold-To Customer Master. The ability to convert a Ship-To, Bill-To or Payer Customer Master into a Sold-To obviates the need to create a new Sold-To and then sunset the old Customer Master created for one business activity.

Some Customer Master cleansing tasks require additional steps to eliminate risk to business continuity. These are tasks required to sunset duplicate Customer Masters—especially those with transactional history.

The XD02 or XD05 transaction can be used to block for a Customer Master the creation of documents for sales, delivery, orders and billing at the divisional level and system level for the purpose of sunsetting. Where the duplicate Customer Master being eliminated has active divisional activity, the non-duplicate Customer Master that is to remain active in the system must be extended to the Company Code and Sales Org of the duplicate Customer Master in order to eliminate the risk to business continuity.

The XD02 or XD06 transaction can be used to flag for deletion Customer Masters that have no open transactional documents and are ready to be sunset. Customer Masters with open transactional documents should only be flagged for deletion at divisional levels that have no open transactional documents.

When a Customer Master has no open transaction documents and has been sunset, the XD02 transaction can be used to add a note to the name or Search Term 1 with the number of the survivor Customer Master that will remain in the system. This reduces the effort to find the survivor Customer Master and reduces the risk that users will ignore messages regarding the status of the victim Customer Master and still use it to post Sales Orders.

A great way to get users to self-police is by adding a popup message to the Customer Master that appears when creating a Sales Order. The message should explain that the victim Customer Master is being sunset and instruct the user to transact with the customer using the survivor Customer Master instead.

Explain why duplicate Customer Masters must not be used.

When explaining to one division that a Customer Master they have been using is going to be rolled up into a Customer Master that another division has been using, there will naturally be pushback and the inevitable question will be, “What is the benefit?” The benefit is that problems caused by having duplicate customers are resolved—preemptively in some cases—and this is a short, but by no means complete, list of those problems.

• The organization might sell to customers in bad standing.
  When a customer stops paying their bills, the appropriate action in SAP is to block them for orders and deliveries by using transaction XD05 or, at the very least, to lower their credit by using transaction FD32. When customers are represented by multiple Customer Masters, it is still possible for them to order and receive goods and services despite being blocked for orders or having their credit lowered elsewhere in the system.

• Customers may have too much credit.
  Credit limits are managed in the Customer Master at the system level independent of internal division. When a customer qualifies for $100,000 in credit and the system has four unique Customer Masters representing the customer, the customer has a cumulative credit with the organization of $400,000.

• Customers might have the wrong address or phone number.
  When a customer calls or writes to report that they have moved or changed phone numbers, the internal resource will likely change only the address on the first Customer Master he finds or only on the Customer Master that his division is using to transact with the customer. Sales Orders created using Customer Masters with the wrong address will inevitably be delayed, returned or even lost and invoices may not be paid on time.

• Customers may not receive discounts, pricing and rebates they are promised.
  After negotiations with a customer are complete (which are probably happening every year), price conditions applied to one Customer Master are not automatically applied to every other Customer Master representing that customer. Furthermore, calculating cumulative volume discounts and rebates based on sales spread over multiple Customer Masters is impossible to automate and a tedious manual chore at best.

• Customers may be penalized despite paying invoices within a grace period.
  The payment terms are often part of the negotiation process and payment terms are applied to a Customer Master to ensure a customer is given a grace period in which to pay invoices. This is not automatically applied to every Customer Master representing the customer. No customer wants to lose a discount or be accused by a bill collector of acting in bad faith when he is complying with the payment terms that were negotiated before a sale.

• Customers may not receive the product they order.
  A Customer Material Info record includes the layman name or material number (rather than a technical name or seller’s material number) that a customer uses to order a material. Having that information at hand while creating a Sales Order eliminates the risk and embarrassment of selling the wrong material to the customer and further obviates the need for the customer to explain what he is trying to order each time he orders it or to record the seller’s internal material number. Creating a Customer Material Info record for one Customer Master does not automatically create one for every Customer Master representing a customer.

• Customers may not receive deliveries on time.
  Customer Material Info records include the delivery priority and fulfillment plant values that override the values in the Customer Master when he buys a specific material, however, creating an Info record for one Customer Master does not automatically create Info records for every Customer Master representing that customer. If a customer has been promised (and paid for) high priority delivery from a nearby plant, but instead receives regular priority delivery from a more distant plant then the inevitable outcome is disappointment.

• Correspondence to customers is duplicated.
  Sales campaigns are a great way to let customers know about deals that the organization is offering, but multiple copies arriving simultaneously feel impersonal despite being personalized.

• Payments from customers may be lost or misdirected.
  Receiving payments from a customer is an easy task if they include the invoice number and only a little more difficult without the invoice number when the customer exists just once in the system. Crediting accounts when payments are received is more difficult and crediting the wrong account can lead to an embarrassing collection call or repeated invoices even after the customer has paid his bill.