Business Central Customer Master Data: Setup & Management Guide [2026]

Customer Master Overview: The Foundation of Sales Operations

The customer master (the Customer table in Business Central) is the central data hub for all customer-facing transactions. Every sales order, invoice, payment, and interaction references a customer record. A well-designed customer master enables efficient order processing, accurate revenue recognition, effective credit management, and powerful business intelligence.

Conversely, poor master data quality causes cascading operational problems: duplicate customer records, incorrect billing addresses, inaccurate credit limits, missing tax information, and reporting confusion. Implementing a disciplined customer master setup and maintaining data quality is one of the highest-impact investments an organization can make during Business Central implementation.

This guide covers the anatomy of the customer card, setup best practices, posting groups, credit management, data migration, and ongoing maintenance strategies.

Customer Card Anatomy: Fields & Categories

The Customer Card: General Tab

The customer card in Business Central is divided into logical sections:

Section	Purpose	Key Fields
General Information	Identify the customer	No., Name, Name 2, Address, City, Post Code, Country, Contact
Business Classification	Posting & accounting rules	Gen. Bus. Posting Group, Customer Posting Group, Tax Area Code, VAT Reg. No.
Sales Settings	Default sales rules	Salesperson Code, Customer Price Group, Customer Discount Group, Currency Code
Payments & Credit	Payment terms & credit control	Payment Terms Code, Payment Method Code, Credit Limit, Blocked, Preferred Bank Acct
Shipping	Delivery preferences	Shipment Method Code, Shipping Agent Code, Location Code
Invoicing	Billing address & document preferences	Bill-To Customer No., Invoice Disc. Code, VAT Bus. Posting Group
Communications	Contact & notification methods	Phone, Fax, Email, Home Page, Contact Name
Statistics & Analytics	Customer performance & segmentation	Customer Class Code, Industry Code, Territory Code, Global Dimension 1 & 2

Required vs. Optional Fields

When setting up a customer record, Business Central enforces certain required fields while others are optional. Understanding this distinction helps streamline data entry and avoid validation errors.

Required fields (must be populated to save customer):

• Customer No.: Unique identifier (assigned automatically or manually)
• Name: Customer legal name or trading name
• Gen. Bus. Posting Group: General posting group for GL account mapping (e.g., “DOMESTIC”, “EXPORT”)
• Customer Posting Group: Sales posting group for revenue GL account mapping (e.g., “WHOLESALE”, “RETAIL”)

Optional but highly recommended:

• Payment Terms Code: Defines Due Date calculation on invoices (e.g., “NET 30”, “2/10 NET 30”)
• Currency Code: If customer transacts in foreign currency (defaults to base currency)
• Credit Limit: Maximum outstanding balance allowed before hold/block
• VAT Registration No.: For VAT/GST compliance and reverse-charge rules
• Salesperson Code: Assignment for commission tracking and reporting
• Dimension codes: For cost center, department, or region tracking

Commonly overlooked fields that cause problems:

• Bill-To Customer No.: If blank, invoices bill to the customer itself. If populated, invoices bill to the linked customer (useful for multi-branch customers with centralized billing)
• Location Code: If your company has multiple warehouses, this default location is used on sales orders
• Blocked status: Controls whether the customer can be selected on sales orders (can be set to “All”, “Shipping”, “Invoice”, or empty)
• Invoice Disc. Code: If you offer customer-specific invoice discounts, this links to the discount schedule

Customer Posting Groups: Mapping to GL Accounts

How Posting Groups Work

Posting groups are the bridge between transaction details (e.g., a sales invoice) and general ledger accounts. When you post a sales invoice to a customer with posting group “RETAIL”, Business Central looks up the “RETAIL” posting group to determine which GL accounts to debit/credit.

Two posting groups apply to customers:

1. General Business Posting Group (Gen. Bus. Posting Group)

Controls GL account mapping for:

• Sales VAT account (outbound VAT liability)
• Receivables GL account (customer balance sheet)
• Sales discount given GL account
• Purchase VAT account (if applicable to this business type)

Common values: “DOMESTIC”, “EXPORT”, “EU” (for VAT rules)

2. Customer Posting Group (Customer Posting Group)

Controls GL account mapping for:

• Sales account (revenue recognition)
• Sales invoice discount account
• Sales credit memo account
• Customer payment discount account

Common values: “WHOLESALE”, “RETAIL”, “INTERNAL”, “GOVERNMENT”

Example: Posting Flow

Assume you post a sales invoice to Customer C001 (Customer Posting Group: “RETAIL”, Gen. Bus. Posting Group: “DOMESTIC”):

1. BC looks up the Customer Posting Group “RETAIL” and finds: Sales GL Account = 4000 (Retail Revenue)
2. BC looks up the Gen. Bus. Posting Group “DOMESTIC” and finds: Receivables Account = 1200 (Accounts Receivable), VAT Account = 2200 (Sales VAT Payable)
3. BC posts the following GL entries:
   • Debit 1200 (A/R): $1000
   • Debit 2200 (VAT): $100
   • Credit 4000 (Revenue): $1000
   • Credit 2200 (VAT): $100

If Customer C001 were instead assigned posting group “WHOLESALE” (Sales GL Account = 4100 Wholesale Revenue), the GL postings would differ even though the transaction amount is identical.

Common Posting Group Setup

A typical company might define:

Customer Type	Customer Posting Group	Gen. Bus. Posting Group	Revenue GL Account
Retail stores (small orders)	RETAIL	DOMESTIC	4000
Wholesale distributors	WHOLESALE	DOMESTIC	4100
International customers	RETAIL or WHOLESALE	EXPORT	4000 or 4100
Government & public sector	GOVERNMENT	DOMESTIC	4200
Internal/inter-company	INTERNAL	DOMESTIC	4500 (Inter-co Revenue)

Payment Terms & Methods: Credit Policies

Payment Terms: Due Date Calculation

Payment Terms define how the due date is calculated on invoices. When you assign Payment Terms Code (e.g., “NET 30”) to a customer and post an invoice on Jan 1, Business Central calculates the due date using the payment term formula:

Common payment terms:

• COD (Cash on Delivery): Due date = Invoice date (immediate payment expected)
• NET 15: Due date = Invoice date + 15 days
• NET 30: Due date = Invoice date + 30 days (most common B2B)
• NET 60: Due date = Invoice date + 60 days (longer credit period)
• 2/10 NET 30: 2% discount if paid within 10 days, otherwise full amount due in 30 days
• End of Month: Due date = last day of invoice month or next month (depending on invoice date)

Payment terms are critical for:

• Accounts Receivable aging reports (identify overdue invoices)
• Cash flow forecasting (when to expect payment)
• Discount calculations (early payment incentives)
• Collection prioritization (high-priority customers with stricter terms)

Payment Methods: How Payment Is Received

Payment Method Code defines the mechanics of payment receipt (e.g., check, wire transfer, credit card):

Payment Method	Example	GL Impact
CHECK	Customer mails a check	Post to Check Clearing account, then to Bank once cleared
WIRE	Customer wires funds electronically	Post directly to Bank account
ACH	Automated Clearing House (US)	Post to Bank; match to ACH feed
CC	Credit card payment	Post to Credit Card Clearing account, then to Bank after settlement
EFT	Electronic Fund Transfer	Post to Bank (similar to ACH)

Credit Management: Limits, Holds, & Blocks

Credit Limit & Status

Business Central supports proactive credit management to prevent overselling to undercapitalized customers:

Credit Limit: Maximum outstanding balance (invoices + orders) allowed for the customer. When the outstanding amount approaches or exceeds the limit, BC can block further orders.

Blocked field: Can be set to one of three values:

• Blank: Customer is fully active; all transactions allowed
• “Invoice”: Prevent invoice posting; useful if customer is disputing charges or has payment issues. Orders can still be created and shipped.
• “Shipping”: Prevent shipment of orders; useful for hold pending credit approval. Sales orders can be created but not fulfilled.
• “All”: Prevent all transactions (orders, invoices, payments). Emergency block for insolvent customers.

Example credit management workflow:

1. New customer “ABC Corp” applies for account. Credit limit set to $50,000
2. Customer places first order for $25,000. Outstanding = $25,000 (below limit)
3. Customer places second order for $30,000. Outstanding = $55,000 (exceeds $50K limit)
4. BC issues warning; credit manager must approve order or adjust limit
5. Credit manager approves order; 30 days later customer owes $55,000
6. Payment of $30,000 received; outstanding = $25,000 (below limit again)

Collection Contact & Tracking

Optional fields for collection efforts:

• Collection Contact Name: Name of person responsible for payments at customer
• Last Date Modified: Auto-populated; shows when customer record was last changed
• Bank Account field: Customer’s preferred bank account (for wire transfers)
• Preferred Bank Acct field: Which bank account to use for payments

Customer Templates: Standardized Setup

What Is a Template?

A customer template is a pre-configured customer record used as a blueprint when creating new customers. Instead of manually entering the same posting groups, payment terms, and settings for every customer, you create a template once and reuse it.

Template Setup

Customer Templates are managed in Administration > Setup > Customer Templates. A typical template includes:

• Gen. Bus. Posting Group
• Customer Posting Group
• Payment Terms Code
• Currency Code (e.g., USD for US customers)
• Salesperson Code (e.g., assign to “Territory North” salesperson)
• Default dimension codes
• Shipping method
• Credit limit template
• Invoice discount code

Common Template Definitions

Template Name	Use Case	Default Settings
DOMESTIC-RETAIL	Small domestic retail shops	RETAIL posting group, NET 30 terms, $10K credit limit, USD currency
DOMESTIC-WHOLESALE	Domestic wholesale distributors	WHOLESALE posting group, 2/10 NET 30 terms, $100K credit limit, USD currency
EXPORT-STANDARD	International customers	EXPORT posting group, NET 45 terms, EUR currency, specific salesperson
GOVERNMENT	Public sector entities	GOVERNMENT posting group, NET 60 terms, high credit limit, strict approval workflow

Data Migration: Moving Customers from Legacy Systems

Migration Planning

Migrating customer master data from a legacy system (SAP, old Dynamics NAV, standalone database) to Business Central requires careful planning:

Pre-migration steps:

1. Data audit: Export all customers from legacy system; identify duplicates, incomplete records, obsolete accounts
2. Mapping: Map legacy customer fields to BC customer fields (e.g., legacy “CUST_TYPE” → BC “Customer Posting Group”)
3. Cleansing: Remove inactive customers; standardize names, addresses, phone numbers
4. Validation: Ensure all customers have required BC fields (customer no., name, posting groups)
5. Testing: Load a sample batch (50 customers) and verify integrity
6. Full migration: Load all customers in final preparation period (day before go-live)

Common Data Quality Issues During Migration

Issue	Cause	Fix
Duplicate customers (same company, multiple records)	Legacy system allowed duplicate entry	Merge or delete duplicates before migration; consolidate outstanding balance
Missing customer numbers	Legacy system auto-generated; format differs from BC	Map legacy ID to BC customer no.; use standardized numbering scheme
Blank required fields (name, posting group)	Legacy system had different requirements	Populate from other data sources; reject if impossible
Invalid email addresses or phone numbers	Data entry errors over years	Validate format; remove or clean invalid entries
Multi-currency setup mismatch	Legacy system used different currency codes	Map legacy currency to BC currency; recalculate in base currency
Inactive/obsolete customers	Customer no longer does business but record not deleted	Archive (set Blocked = “All”) or delete if no outstanding balance

Migration Tools

• RapidStart Services: BC built-in import tool for bulk master data (config worksheet approach)
• Data Migration Toolkit: ISV tools (Wifac, Rapid5, etc.) automate legacy system extraction and mapping
• Power Query / Excel: For small migrations (< 1000 customers), manual mapping in Excel is acceptable
• API integration: For ongoing syncs (e.g., Salesforce CRM → BC), use integration middleware (Celigo, MuleSoft)

Customer Dimensions: Analytics & Reporting

Global Dimensions 1 & 2

Dimensions allow you to segment transactions for analysis without modifying chart of accounts. Common dimensions assigned at the customer level:

Global Dimension 1 (often: Department or Cost Center)

Example: Department { Manufacturing, Sales, Administration }

When you post a sales transaction to a customer with Department = “Manufacturing”, the dimension value flows to the GL entry, enabling reporting by department.

Global Dimension 2 (often: Region or Territory)

Example: Territory { North America, Europe, Asia-Pacific }

Shortcut Dimensions 3-8 (optional)

Additional dimensions for granular analysis (project, customer segment, salesperson, etc.)

Use case: At year-end, you run a profit/loss report filtered by Department and Territory, giving you visibility into revenue and costs by both organizational unit and geography.

Customer Price Groups & Discounts

Price Groups: Customer-Specific Pricing

Business Central allows you to assign a Customer Price Group, which links to a pricing table defining item prices for that customer group:

• RETAIL: Customer sees list prices (no discount)
• WHOLESALE: Customer sees 15% discount on all items
• VIP: Customer sees 20% discount plus free shipping
• GOVERNMENT: Customer sees government pricing (often negotiated per item)

When a sales order is created for a customer with Customer Price Group = “WHOLESALE”, BC automatically pulls wholesale prices from the Sales Price list.

Invoice Discounts: Line-Item & Total Discounts

Invoice Discount Code links to a discount schedule that applies based on order total:

Example discount schedule for Code “RETAIL-SMALL”:

• Orders $0-$999: No discount
• Orders $1,000-$4,999: 3% discount
• Orders $5,000+: 5% discount

When a sales order total reaches $5,000, the 5% discount automatically applies to the invoice.

Ship-To Addresses: Multi-Location Delivery

Primary Address vs. Ship-To Addresses

A customer record includes one primary address (billing address). But customers often have multiple delivery locations (retail locations, warehouses, project sites). Ship-To Address records allow this:

Example: Large retailer ABC Corp

• Primary address (billing): 100 Corporate Way, New York, NY (HQ)
• Ship-To Address 1: 500 Store #1 Ave, Boston, MA (Store #1)
• Ship-To Address 2: 300 Store #2 Lane, Philadelphia, PA (Store #2)
• Ship-To Address 3: 400 Distribution Center Dr, Atlanta, GA (DC)

On a sales order, you select the ship-to address, and items are delivered to that location instead of the primary address.

Ship-To Setup

Ship-To Address records are managed on the customer card (Addresses button). Each address includes:

• Code (e.g., “STORE1”, “DC”)
• Address, city, postal code, country
• Location code (default warehouse location for this ship-to)
• Shipping agent code (preferred carrier for this address)

Customer Segmentation: Analytics & Marketing

Segmentation Fields

Business Central provides several fields to segment customers for targeting and analysis:

• Customer Class Code: Large, Medium, Small (by revenue or employee count)
• Industry Code: Manufacturing, Retail, Services, etc. (for industry analysis)
• Territory Code: Sales territory or region
• Salesperson Code: Assigned account manager
• Customer Posting Group: Transaction routing (also a business classification)

Segmentation Use Cases

• Marketing campaigns: Filter customers by industry and size to target email campaigns
• Sales performance: Analyze revenue by salesperson and territory
• Credit decisions: Tighten credit limits for Small customers; relax for Large customers
• Pricing strategy: Offer volume discounts to Large customers in specific industries

Data Quality Best Practices: Maintaining Master Data Integrity

Validation Rules at Entry

Implement validation logic (via AL extensions or configuration) to prevent bad data from entering the system:

• Mandatory fields: Enforce customer no., name, posting groups, payment terms
• Duplicate detection: Alert if customer name or VAT number already exists
• Credit limit sanity: Warn if credit limit is unreasonably high (e.g., $999M for a small retail shop)
• Email/phone format: Validate email format and phone number length
• Posting group existence: Ensure selected posting groups exist (prevent “TYPO” posting group assignment)

Periodic Audits

Schedule quarterly or annual customer master audits:

1. Duplicate report: Run duplicate detection by customer name, tax ID, or email
2. Inactive customers: Identify customers with no transactions in past year; archive if appropriate
3. Missing data: Report customers missing required fields (payment terms, salesperson, posting group)
4. Outliers: Identify unusual credit limits, payment terms, or postings groups that may indicate data entry errors
5. Address validation: Validate customer addresses against postal databases (optional but valuable)

Data Governance

Assign roles and responsibilities:

• Master data owner: Designates who is responsible for customer master accuracy (often Sales Operations or Finance)
• Approval workflow: New customers require credit manager or sales director approval before creation
• Change log: Track who modified customer records and when (BC provides audit log)
• Training: Ensure all staff creating customer records understand required fields and posting group logic

Frequently Asked Questions

Can a customer have multiple billing addresses?

A customer record has one primary billing address. For alternate billing locations, use ship-to addresses and set the Billing-To Customer No. to link a secondary customer record (if bills are truly separate) or use ship-to addresses for delivery while billing to the primary address.

What happens if I change a customer’s posting group after transactions are posted?

Previously posted transactions retain their original posting group (GL impact is locked in). Only new transactions use the updated posting group. Changing posting groups retroactively requires manual GL reversal entries and is generally avoided.

How do I handle a customer with multiple legal entities (e.g., parent company and subsidiaries)?

Create separate customer records for each legal entity if they have distinct billing addresses, credit limits, or payment terms. Use Bill-To Customer No. to consolidate billing if invoices should be sent to the parent company.

Can I block a customer from placing orders without blocking invoicing?

Yes. Set Blocked = “Shipping” to prevent shipment of new orders while allowing invoicing of existing shipments. This is useful for customers with temporary credit holds.

What is the difference between Customer Posting Group and Gen. Bus. Posting Group?

Customer Posting Group controls which Sales GL account is credited (revenue recognition). Gen. Bus. Posting Group controls which Receivables and VAT accounts are used (balance sheet and tax). Both are required.

How do I handle a customer who operates in multiple currencies?

Set the customer’s Currency Code to their primary currency (e.g., EUR for a German customer). If they occasionally transact in other currencies, manually create multi-currency sales orders and post in the alternate currency; BC will auto-convert to base currency for GL posting.

Can I merge duplicate customer records?

Business Central does not have a built-in merge function. Merging duplicates is manual: redirect outstanding invoices, combine address/contact info, delete the duplicate, then archive the merged record (or delete if no outstanding balance). Consider hiring a partner for large-scale duplicate remediation.

How do I set up invoice-level price overrides (different price per customer on the same item)?

Assign a Customer Price Group to the customer; create a Sales Price record for the item with that price group. Alternatively, use Invoice Discount Code to apply percentage discounts based on order total. For manual overrides on specific invoices, you can manually adjust line prices in the sales order.

Key Takeaways

• Customer master is your foundation: Poor master data cascades into operational problems (duplicate records, billing errors, credit failures). Invest in clean, consistent customer setup.
• Required fields are non-negotiable: Customer no., name, Gen. Bus. Posting Group, and Customer Posting Group must be populated. These are not optional.
• Posting groups are critical for GL accuracy: Understand the distinction between Customer Posting Group (revenue GL) and Gen. Bus. Posting Group (balance sheet GL). Incorrect assignment misroutes revenue.
• Credit management prevents bad debt: Set realistic credit limits, assign payment terms, and monitor outstanding balances. Use the Blocked field proactively for problem customers.
• Customer templates accelerate setup: Create templates for common customer types (retail, wholesale, government); reuse them to ensure consistency and speed data entry.
• Data migration requires planning: Audit legacy data, cleanse duplicates/errors, validate against BC requirements, and test before cutover. Migration is the largest source of post-go-live problems.
• Dimensions enable analytics: Assign global dimensions at the customer level to slice revenue and costs by department, territory, or other business dimensions.
• Segmentation supports strategy: Use customer class, industry, and territory codes to segment customers for pricing, credit, marketing, and territory management.
• Maintain data quality proactively: Implement validation rules, run periodic audits, assign a master data owner, and train users. Prevention is cheaper than remediation.
• Ship-to addresses solve multi-location delivery: Don’t create separate customers for each delivery location; use ship-to addresses instead.