Addressing the Issue

Addressing the Issue

If your ERP implementation includes the revenue cycle, you will probably need to convert customer data to the new financial system of record.  How do you know when to create a new customer record versus when to add an address to an existing customer record?

This article uses PeopleSoft as an example, but the guiding principle applies to any ERP package.

You might have five ACME Corp records with different addresses.  And during a conversion design workshop, someone asks whether these five ACMEs should become:

–        five ACME customer records


–        one ACME customer with five addresses

This sounds like an easy question.  But too often, the response echoes the official system documentation.  The documentation merely states that the system is flexible.  You can add one ACME with five addresses or five linked ACMEs.  And this is all true.  Modern ERP systems are flexible so you could do either one.  But it answers nothing and takes you full-circle back to the question.

Here is some of that advice on breaking the circle and getting to an actual answer.  Think downstream.  For the revenue cycle, this means framing the questions in terms of Accounts Receivable analysis.

Do your AR specialists collect individually on each of the five ACMEs?  If so – strongly consider making these separate customer records.  Yes – you can, in theory, run reports which age items based on customer address.  But step into the shoes of your AR specialists.  They talk to customers and rely on one or two key screens to have the customer account at their fingertips.  But these screens don’t reference a customer address.  They reference a customer.  Shouldn’t you set up your customers accordingly?

There may be other considerations in determining how granular to make your customers, but if you start by asking what level of granularity supports your AR, you’re moving in the right direction.  Rather than drowning in a sea of flexible alternatives, you’re reaching a conclusion based on a business need.  And isn’t that a big reason to implement ERP in the first place?

Add Comment

Your email address will not be published. Required fields are marked *