Privacy and preparation
Personal data hiding in ERP master records
By SourceX Editorial · Reviewed by Noah Loul ·
Short answer
ERP data privacy problems in distribution companies sit mostly in master records, not transactions. Customer, contact, vendor, employee and ship-to records hold names, home addresses, phone numbers, tax IDs and bank details. Keep item, quantity, date and exception fields, replace party records with stable codes, and exclude employee and banking fields entirely.
Key takeaways
- Transactions point to master records, so any export that joins customer or vendor fields pulls personal data along with it.
- Replace customers, vendors and ship-to locations with stable codes; keep the code map inside the company.
- Sole-proprietor vendors and residential ship-to addresses are the hardest cases in a B2B ERP.
- Employee records, bank details and payment card fields are excluded, not transformed.
- Test joins after coding: long IDs mangled by a spreadsheet can silently break the linkage that gives the data its value.
Why do master records carry most of the privacy risk?#
Master records carry most of the privacy risk because they are where an ERP stores who a party is, while transactions store only what happened. A sales order line holds an item, a quantity, a price and a date, plus an internal ID that points to the customer, the ship-to and the sales rep.
The moment an export joins those IDs to their master records, names, addresses, phone numbers and emails come along. A distributor's order exception history can be almost free of personal data on its own and full of it once the customer and contact tables are attached.
Bulk exports make this visible. NetSuite's Full CSV Export, by Oracle's own description, does not export all data; what it does cover includes contacts, customers, employees, notes, partners and vendors. In other words, the default bulk extract is mostly the material that needs the most care.
Saved searches and reports carry the same risk in a quieter form. A custom exceptions report built years ago may already include the customer's contact name and phone in its columns, and teams tend to reuse such reports as a ready-made extract.
Field table: customer, vendor, employee and ship-to records#
The field table below covers the master records a distribution ERP typically holds and a default treatment for each. Field names differ between NetSuite, Epicor and Acumatica, but the record types and the decisions are the same.
| Record | Fields with personal data | Default treatment | Keep |
|---|---|---|---|
| Customer | Name for sole traders, phone, email, billing address, tax ID | Replace with code; remove contact fields | Industry, region at state level, account type, terms |
| Customer contact | Name, title, direct phone, mobile, email | Remove | Role category only, such as purchasing or accounts payable |
| Ship-to and address book | Street address, delivery contact, gate or dock instructions | Generalize to city or ZIP; remove contacts | Location type, dock or residential flag |
| Vendor | Owner name for sole proprietors, tax ID, remit-to address | Replace with code; remove tax ID | Vendor category, lead time, terms |
| Vendor bank and payment | Account and routing numbers, card data | Exclude | Nothing |
| Employee and sales rep | Name, email, territory, pay and HR fields | Exclude HR fields; replace rep with role code | Territory or team code |
| Notes and memo fields | Anything typed by staff | Scan and clean | Operational content after cleaning |
- 01Your work records
- 02Personal details removed
- 03You approve the release
- 04Licensed to AI developers
Where NetSuite, Epicor and Acumatica keep these fields#
NetSuite, Epicor and Acumatica all separate the party from its addresses and contacts, which helps: you can drop whole subrecords instead of cleaning field by field. In NetSuite, customers, vendors, employees, partners and contacts are entity records with address subrecords and attached notes. Epicor keeps customers, ship-to locations, vendors and person-contact records as related tables. Acumatica organizes business accounts, contacts, locations and employees as separate screens and tables.
Be careful with whole-system backups. A guide from an Acumatica partner describes a Full snapshot mode that exports all tenant data in XML or binary format; that is a backup, not a licensing extract, and it should never be the starting point for a package.
Watch long identifiers during preparation. Oracle's NetSuite help warns that opening a CSV export directly in Excel loses precision on numbers longer than 16 digits, and recommends importing such columns as text. A mangled ID can quietly break the join between an order and its coded customer.
Which master records are the hard cases?#
Sole-proprietor vendors and residential ship-to addresses are the hard cases in a B2B ERP, because the business record and the person are the same thing. A one-person trucking vendor's name is a person's name, and its tax ID field may hold a Social Security number rather than an employer ID.
The same applies to small contractor customers who buy under their own names and to drop-ship orders delivered to a homeowner. These records need the strictest treatment in the table even though most of the customer base is commercial.
Business contacts at larger companies still count. California's temporary exemption for business-to-business contact data ended on January 1, 2023, so names, direct lines and work emails of buyers and accounts payable staff may be personal information. Which state laws apply is assessed deal by deal with counsel.
| Hard case | Why it is hard | Treatment |
|---|---|---|
| Sole-proprietor vendor | Business name is a person's name; tax ID may be a Social Security number | Code the vendor; remove name, tax ID and remit-to address |
| Contractor customer under a personal name | Account looks commercial but names an individual | Code the customer; keep trade and region |
| Drop-ship to a homeowner | Ship-to is a residential address with a delivery contact | Generalize to ZIP code; remove contact and instructions |
| Buyer or AP contact at a large customer | Work details of a named person | Remove; keep a role category |
A review sequence for the master-record cleanup#
A master-record cleanup works best as a fixed sequence that operations, IT and finance can each check. The COO owns the scope, IT owns the extract and finance confirms that nothing from the payment side slips in.
Two mistakes recur in this sequence. The first is coding customers in one extract and forgetting the ship-to and contact tables in the next, which leaves names one join away. The second is reusing the same code map across separate licenses to different buyers; separate maps per release make it harder for anyone to combine packages and rebuild a customer list.
- List every master record type joined to the transactions in scope.
- Pull the field list for each record, including custom fields and attached notes.
- Mark each field keep, generalize, code or exclude, using the field table as the default.
- Build the code map for customers, vendors and ship-tos and store it in a restricted location inside the company.
- Extract with IDs imported as text, then test that orders still join to coded parties.
- Scan memo and note fields for names, phone numbers and emails, and review a sample by hand.
- Record the treatment for each field so the next extract repeats it exactly.
Illustrative: an industrial distributor cleans its NetSuite masters#
Illustrative: a fictional industrial distributor wants to license order exceptions, backorder decisions and return reasons from its NetSuite history. The COO assumes the data is impersonal because almost all customers are businesses.
The field review shows otherwise. Ship-to records for drop-ship orders carry homeowner addresses, contractor customers are listed under owners' personal names, and vendor records for owner-operator carriers hold tax IDs that are Social Security numbers. Memo fields include buyers' mobile numbers and notes such as call after lunch.
The team codes all customers, vendors and ship-tos, generalizes residential addresses to ZIP code, excludes vendor banking and tax fields, and replaces sales reps with territory codes. The exception, backorder and return history stays intact, still linked to coded customers, so a buyer can see patterns by account without knowing which account.
How SourceX approaches ERP extracts#
SourceX handles ERP master data in the Preparation step of the SourceX five-step transaction, after the Rights step confirms which records the company can license. The code map stays with the supplier; buyers receive coded records only.
Field-level treatments are recorded in the privacy record of the SourceX Evidence Packet, and the supplier approves them before Delivery. Large extracts can stay in the supplier's own storage, so the ERP never has to be copied wholesale to anyone.
Frequently asked questions
Can we keep customer company names if they are businesses?
Usually not in a licensed package. Even when a customer is a corporation, its name reveals your customer list, and customer contracts may treat the relationship as confidential. Codes plus an industry and region field keep the analytical value without naming anyone.
What should happen to payment card data stored in the ERP?
Exclude it. Card fields have no value for an AI developer, and PCI DSS v4.0 Requirement 3.3.1 says sensitive authentication data such as card verification codes and PINs is not retained after authorization at all. If such data turns up in notes, treat that as a finding for your own security team too.
Should the buyer ever receive the code map?
No. The code map is what turns coded records back into named customers and vendors, so it stays inside the company under restricted access. Buyers can still analyze patterns by code, which is what they need.
Do we need to notify customers before licensing ERP data?
It depends on your privacy notice, customer contracts and the laws that apply to the records. Coded and cleaned data reduces the question considerably, but counsel should review the notice and the contracts deal by deal before anything is licensed.
Are item masters and price lists a privacy concern?
Item masters rarely contain personal data, but they can contain confidential supplier costs and customer-specific pricing. Review them for commercial confidentiality rather than privacy, and remove customer-specific price agreements that identify an account.
Sources
- NetSuite's Full CSV Export does not export all data; it covers accounting lists, classes, contacts, customers, departments, employees, items, notes, partners, saved reports you own, tasks, the transaction detail report and vendors. Opening a NetSuite CSV export directly in Excel loses precision on numbers longer than 16 digits. Source
- A Greytrix guide says an Acumatica Full snapshot exports all tenant data in XML or binary format. Source
- The California Privacy Rights Act set the sunset date for the CCPA employee and B2B exemptions at January 1, 2023. Source
- PCI DSS v4.0 Requirement 3.3.1 states that sensitive authentication data is not retained after authorization, even if encrypted, covering full track data, card verification codes and PINs or PIN blocks. Source
Related resources
- QuestionWho owns enterprise data?
- QuestionDo AI labs buy code?
- InsightCan financial advisors sell their data to AI companies?
- InsightCan data licensing affect my cyber insurance?
- InsightHow do I de-identify financial transaction data for AI training?
- SolutionData partnerships between businesses and AI developers
See if your company qualifies
A short company assessment. No data uploads are needed.