Customer account numbers

started a topic over 8 years ago

It would be nice to be able to add a customer account number when creating a new customer as well as just their name. Xero has an option to assign account numbers to customers which is handy when sending out statements as customers can use their account number as a reference when making payment. Right now I have to add account numbers manually in xero once the customer has been created in DEAR.

50 people like this idea
  • Having an account number would have ensured that customer details were not combined under the same first name...

  • Is that from some sort of integration or pulled from another system?
  • ecommerce orders place in Woo with unique customer record

    imported into DEAR, where customer record is combined into existing record with same name

    passed to XERO where invoice is raises and emailed to the original default contact.

    Woo deals with the customer record correctly - Xero deals with the information passed from Dear correctly.

    Dear incorrectly combines customer record as it is not qualifying the customer recorde correctly.

    Hope this helps...

    1 person likes this
  • Tristan - 

    You ask: "Out of curiosity how would having another unique account number have negated this error?"

    That is the crux of the problem. A unique account number is NOT currently available. The account number is currently based on the customer name. Having a "John Smith" in Houston, TX is considered as the same customer as a "John Smith" in Chicago, IL - when they are obviously not the same.

    1 person likes this
  • Robert - I'm not being argumentative and I'm genuinely trying to help. There are already TWO unique identifiers.

    1)  DEAR generates a unique identifier for each Customer or Supplier.  This identifier is the characters after the # in the Customers URL (in bold below) and can be found by visiting the Customer (Sale > View All Customers then select a customer) and looking at the URL.


    This unique identifier is not manually setable or changeable and is too long to use as a reference on bank payments, however since it's randomly generated you could use, say, the first 8 characters with an extremely low chance of two of your customers having the same first 8 characters.

    This unique identifier is NOT currently available through the available mailmerge fields, although I'm sure this would be a reasonably easy thing for DEAR to add.

    You can access this via the API as well:



    2) The Customer Name field.  A few of the complaints here are that you cannot have two identical names - well that makes it a unique identifier.  Could use the Customer Name field as your account identifier and then use Additional Attributes to store and display their non-unique company name, city, etc?  The Additional Attributes are easy to access from the Mail Merge for using on invoice templates.

  • Hi Tristan -

    I appreciate that you are trying to take the time to understand our problem. Unfortunately, the Dear generated number is not really usable in under most circumstances.


    Regarding the Customer Name field, you are technically correct that it is specified as a unique constraint and does not allow for duplicates just like you state. However just because a field in the database is constrained as being unique, it does not meant that it uniquely identifies the data that it is supposed to represent. If you add a unique constraint on the zip code field you would guarantee that only unique zip codes are entered, but it's obvious that there will be multiple address that need to be represented by that zip code - hence the zip code field is a bad choice as a unique constraint.


    As an example, let’s use you: Tristan Thomas


    1) You place an order on Shopify for a large screen TV.

    2) Dear Systems downloads the order

          a) a Tristan Thomas customer is created (located lets say in New Zealand).

    3) Tristan Thomas (the basketball player from upstate SC) places an order on Shopify for 5 pairs of shorts

    4) Dear Systems downloads the order

          a) the Tristan Thomas customer is found based on the Full Name match

                    i) the account is updated to show the new purchase.

    5) Now you call us and ask us what your last purchase was, because you want to duplicate it

       a) we will gladly tell you that you ordered 5 pairs of shorts.

       b) you tell us that you never ordered shorts

             i) now we need to figure out what happened and take time to correct the integrity of our data.

       c) I finally find that it was a large screen TV that you ordered (it's not easy in Dear to see what was shipped to New Zeeland)

       d) I ask you to place all future orders as “Tristan Thomas – NZ” or “Tristan Thomas #1

             i) You basically LYAO at us.


    How would you suggest that I handle the above scenario - it's happens in our line of business (especially with company names)?

    Really, there are two issues at play here:

    1) Not being able to have two Tristan Thomas accounts - that could be differentiated by a customer account code


    2) The Shopify account matching logic - it would need to match on more than just full name and create an account if a strong match was not identified - e.g. email, phone, or address 

    (the accounts could be combined later if they were as being the same customer).


    The issue shown in the above example is really keeping me from moving forward with fully implementing this system – even though I’ve been paying for it during the last few months.


    Thanks for your time.


    1 person likes this
  • This strikes me as an issue with the integration, not DEAR per se.  DEAR could have an extra 150 unique fields but you're always going to run into the same issue - what are you going to match a non-unique customer name against?  

    As you say in point (2) the integration needs to check multiple fields for a best match, but natural language processing / matching is extremely difficult.  You and I are good at seeing that "Unit 1 123 Main Street" is the same address as "123 Main St Unit 1" but that's a really difficult for a computer.  Matching email address is a better option but many people use different emails as they change employment etc.  Matching off a woocommerce / shopify account number would work but only if the customer signs in with the same account and not as a guest.

    Ideally the integration would look at a couple of points - maybe name, address, email address and make a decision on best match.  If the integration can't confidently match then it should ask for manual help.

    But regardless I can't see how an additional DEAR field will solve this?

  • @Tristan Thomas, it blows my mind how you are the one replying to these sorts of requests.

    you seem unable to simathise with what we have asked for for multiple reasons.

    we aren't asking, as you said on Saturday 28th, for 150 different custom fields, this is one field that would help our businesses opperate better.

    the unique # that is in the URL would work internally, but not to share with a customer.

    the name is obvious, but as mentioed, in many situations, it's not good enough.

    I'd still like the feature of selecting between:

    • numbers for Cash customers (can be auto generated, preferably 4 or 5 digits, no more)
    • initials for account customers (set by us)
    all these will make it easier to allocate payments when they put their account number in the bank transfer refference.

  • it would be more professional to lie and say:

    "it's up for consideration, but not a high priority. it will be sceduled into the roadmap of improvements for a later date"

  • Michael are you aware that I do not work for DEAR?  I'm simply a user like you and I'm trying to help you think about your process so that you can try to solve you issues using existing functionality.

    You might notice that this topic has been marked "deferred" which means exactly what you state: not a high priority and might be looked at later in the future.

    If you are unable to change your workflow and you rely on having a unique account number then I'd suggest one of two things:

    1) Use the last X characters of the DEAR-created customer ID as your unique account number.  While strictly not unique the chance of these strings being duplicated is tiny.

    2) Use the "Customer Name" field in DEAR as your unique account number and add their name or business name as an Additional Attribute.

  • Well I kept having my post rejected, so I will try to remove the concern the forum gatekeeper was possibly having with it.

    Regarding having a separate unique CustomerID field and the shopify concerns here's one way to do it:



    CustomerID: 1000, 

    Name: John Smith, Address: 123 Main St Unit 1, City: Houston, St: TX

    Email:, Phone: 811-555-1212


    CustomerID: 5555, 

    Name: John Smith, Address: 500 Michigan Ave, City: Chicago, St: IL

    Email:, Phone: 313-222-5555


    NOTE: Two John Smith accounts are allowed because the CustomerID field has the unique constraint.

    Another order comes in from shopify: (using the mangled address example)

    Order info:

    Name: John Smith, Address: Unit 1, 123 Main St, City: Houston, St: TX

    email:, Phone: 111-111-2222


    Check the "strong" indicators of the order first for a match.

    "strong" match indicators would be: email, phone, Name/Address (including city, state, and zip)

    This order matches on email -> the order is added to CustomerID 1000.


    Now if the email wasn't provided, we no longer have an email, phone, or address match.

    A new account is created:

    CustomerID: 8787,

    Name: John Smith, Address: Unit 1, 123 Main St, City: Houston, St: TX

    Email: none  Phone: 111-111-2222


    Now later when our customer service rep searches on John Smith, all three accounts come up (1000, 5555, 8787) and hopefully our customer service rep can verify with the customer, assuming he/she is on the phone, that account 8787 is the same as account 1000 - e.g. maybe the cell phone was provide instead of the main number. Now our customer service person can merge the two accounts.  If they are not the same person then there is no harm done, because all the accounts are separated appropriately.


    I know this is a simplistic example, but hopefully it illustrates the reason why a non unique Name field and a unique CustomerID field would solve many issues.


    This would also allow our customers to refer to their customer id (original request in thread). e.g This is John Smith, can you tell me if I have an account balance? My customer id is: 1000; no confusion, very simple and elegant. 


  • The fact that Dear uses the Customer Name as a unique identifier is a joke. 
    Even if you don't want to implement account numbers (noting that this feature request is marked as deferred), at very minimal it should use email address or phone number as the unique identifier in which to avoid duplicates.

    In addition to our B2B customers, we have multiple B2C ecommerce shops connected to Dear, all of which are syncing customers to Dear, so the chances of duplicate customer names (e.g. John Smith!) are relatively high!

    We've just had the exact situation happen whereby 2 completely separate customers with the same name have been merged into the same Customer by Dear....

    Please guys, let's get this sorted.

  • Completely agree Account numbers are needed.   Every system I have ever used has account numbers. 

    1 person likes this
  • I also completely agree, account numbers are needed. Unique account numbers would obviously allow more robust cross-linking to other data sources. 5 years on and this discussion is still going? Maybe this is why it has never been done. DEAR doesn't want to give away too much.

  • HI Steve, your speculation is wrong, which I hope makes you feel a bit better about the world .  Of course Dear uses unique identifiers, they are GUIDs and are exposed everywhere in the API. Every integration uses them, not just for customers, but for everything. See the API docs. GUIDs are very cool, they are account numbers on steroids, but they are very big. They solve a lot of problems for programmers, but they are not remotely human friendly.

    Robert Thomson's post is a good one. The current situation causes problems in the B2C world. But this problem is quite hard to solve. Account numbers don't help very much. For sure, customer names should not have uniqueness forced upon them, but then what? I don't want my B2C customers to have to remember their Dear account number, it's of no value to them.

    1 person likes this
Login or Signup to post a comment

50 people like this idea
Log in or Sign up to post a comment