It really boils down to how the custom fields were added.

If a field was added to a form via the Customizer module, I believe there the binding information will be in the customization data for that field.

If a field was added by you or your partner via a source code modification, check the source code for the binding or contact your partner.

Using a brute force method, you could use SQL Profiler.  Get to a form that has the field.  Start Profiler, and then modify a customized field and see where the fields being updated.  

Neither of the options you listed...

hopefully this gives you an idea:

mas500 menu path:

a/r module/maintenance/ar setup/setup ar options/custom (tab)/custom fields (open to 4 customer fields that can be used for customer and 2 custom fields for salesperson).

Within the custom fields menu there are 2 entities that can be used for custom field along with custom title and values; customer is one and salesperson is the other.

We setup a customer field named customer type for the customer entity.  Added the descriptions/values.  The values are viewable in the custom field menu as well as the maintain customers/default (tab) custom fields section.  The description, customer type and the values entered are viewable.    

The question is what table contains the data and shows the description "customer type" and the values for customer type.

Looked at 30 different tables and didn't find the data...

Appreciate the assistance.

The Sage 500 custom field values are normalized in the base entity or document table you have chosen to configure. In practical terms, given your example, this means that a custom field value configured for a customer is stored in the tarCustomer table with a prefix of UserFldx. The number of custom fields available in native Sage features is specifically limited by the number of these user fields present in the base table. To view these values in a report you need to add the UserFldx field that represents the custom field data to the body or header. If you have already added the base table to your report, the custom field should already be included in the field collection. It may or may not be available with native Sage reports, but it generally is referenced as some variation of UserField, CustUserField or similar when it is available.

The fields are sequential, so the one that appears at the top in Set Up AR Options is UserFld1, while the second is UserFld2, etc. The value stored in the table does not represent the metadata, restrictions or validations you have configured for the custom field, which are indicated and enforced in the application code. This data is stored in the tciUserField, tciUserFieldUsed and tciUserFieldValue tables and while there is some translation that is needed for input, as well as to normalize the output, the metadata can be obtained using the spciGetUserFieldValues stored procedure (relationships and column metadata are also detailed in the Schema Browser). 

The following example returns the metadata from SOA demo data for user field 1 associated with a customer (entities defined in tciEntity):

EXECUTE [dbo].[spciGetUserFieldValues]
@_iCompanyID = 'SOA',
@_iUserFldNo = 1,
@_iEntityType = 501;

A tip on custom reports is to avoid creating these by directly referencing schema because the Crystal report engine prefers to lock the data it references, and it may pull all data into the report before it applies a filter or groups the data for aggregate operations. Although you can avoid some of that with report settings and configuration, creating a view, stored procedure or function to properly handle the data translation, joins and aggregations is typically a better choice. If you create a report by directly referencing schema, you also must perform your own metadata translations, so you might want to review the many customer-centric views like vdvCustomer (the BIE customer view) to begin an optimized build of your own.