How to Create a Customer Account Group in SAP – Step-by-Step Guide

✅ Creating a New Customer Account Group in SAP

Create Customer Account Group - a step-by-step guide. Customer account groups classify customers into categories for consistent master data management. Creating a new one is a project-specific decision, driven by whatever distinct customer categories the business genuinely needs to track separately - Sold-to Parties, Ship-to Parties, one-time customers, intercompany customers, and so on.

SAP delivers a set of standard account groups out of the box, and in many implementations these standard groups are sufficient without any customization. But whenever a business has a customer category that needs its own number range, its own screen layout, or its own downstream processing behavior distinct from the standard groups, creating a new account group - rather than forcing that category to share a group it doesn't quite fit - is the cleaner, more maintainable approach.

This guide uses a Sold-to Party account group, coded E001, as a concrete example. Sold-to Party is one of the four standard partner functions in SAP SD - the customer who actually places the order, as distinct from the Ship-to Party (who receives the goods), the Bill-to Party (who receives the invoice), and the Payer (who settles payment) - and it's a common candidate for a dedicated account group in many implementations.

📋 Creating vs. Configuring the Screen Layout: Two Sides of the Same Transaction

It's worth being clear that creating a new account group and defining its screen layout both happen inside the same OBD2 transaction, but they represent two conceptually distinct decisions. Understanding the difference avoids confusion when working through the configuration.

In practice, these two steps almost always happen together - a new account group is created and its field status reviewed in the same configuration session, exactly as shown in the walkthrough below.

🔧 SAP SD: Create New Customer Account Group – Step-by-Step

Like most SAP configuration, creating a new account group is typically done by copying an existing one as a starting point, rather than building every setting from a completely blank entry.

1

Run transaction OBD2 directly, or follow the IMG path: SPRO → Financial Accounting (New) → Accounts Receivable and Accounts Payable → Master Data → Preparations for Creating Customer Master Data → Define Account Group with Screen Layout (Customers).

2

Select New Entries to create a new customer account group. The exact code and category chosen depend on your project - in this example, the group is created to represent a Sold-to Party customer, coded E001.

3

Enter a clear description for the group, confirm the account group category (customer), and review the number range and general settings that apply. Since this group represents a Sold-to Party, confirm the field status supports whatever level of detail Sold-to Party records genuinely need - typically fuller address, tax, and payment term information than a simpler customer category might require.

Why this step matters: Whatever code and category are chosen at this stage becomes the customer account group used for the life of the system - renaming or restructuring it later, once real customers exist under it, is considerably more disruptive than getting the code and category right the first time.

📋 Choosing the Right Code and Category for a New Account Group

Because account group creation is genuinely project-specific, there's no single universally correct code or naming pattern - what matters is that the choice is deliberate and documented, rather than arbitrary. A few considerations are worth weighing before finalizing a new account group's code:

• Does the business genuinely need a distinct category, or would an existing standard account group, possibly with a minor field status adjustment, already cover the need?
• What number range should this category draw from - and should numbering be internal (system-assigned) or external (user-entered), which is a common distinction between customer categories like Sold-to Party versus Ship-to Party?
• Does the code fit an existing naming convention already in use across the project, so future consultants can recognize the pattern without needing to look each one up individually?
• Will this account group need a genuinely different screen layout from existing groups, or is it primarily being created for a separate number range or downstream processing distinction?

Working through these questions before creating the group avoids the common trap of ending up with several overlapping account groups that all serve nearly the same purpose, making the customer master landscape harder to understand over time.

❗ Common Mistakes When Creating a Customer Account Group

• Creating a new account group without first confirming an existing standard group couldn't already be adjusted to meet the need, resulting in unnecessary duplication.
• Choosing a code or naming pattern that doesn't fit the project's existing conventions, making the new group harder for future consultants to recognize and understand.
• Leaving the number range unreviewed after creation, resulting in customer numbers being issued from an unintended or poorly planned range.
• Creating the account group but never reviewing its field status afterward, leaving it with settings inherited from whatever group it was copied from rather than settings genuinely suited to the new category.
• Reusing SAP's own standard demo account groups for live, production customer data instead of creating dedicated, project-specific groups.
• Making this configuration directly in a production client instead of testing a sample customer creation in a sandbox or development client first.

✅ Best Practices for Creating Customer Account Groups

• Confirm the business genuinely needs a distinct account group before creating one, rather than defaulting to a new group for every minor variation in customer type.
• Agree on a naming and numbering convention early in the project, so every account group created afterward follows a consistent, recognizable pattern.
• Create new account groups by copying an existing, well-configured one, then deliberately review the field status and number range rather than accepting the copied defaults blindly.
• Document the business reason behind each account group, particularly project-specific ones like a dedicated Sold-to Party group, so the purpose remains clear long after the original implementation team has moved on.
• Test a sample customer creation under the new group in a sandbox or development client before considering the configuration complete.
• Move configuration changes like this through a transport request and test them in the Quality system before they reach Production, the same as any other configuration change.

📈 How Account Group Relates to SD Partner Functions

Because this guide uses Sold-to Party as its example, it's worth briefly connecting account group back to how partner functions work in SD. Every sales order references a set of partner functions - Sold-to Party, Ship-to Party, Bill-to Party, and Payer - which can all be the same customer or different ones, depending on the business scenario. A customer's account group doesn't determine which partner function it can play on an order, but it does shape what master data is captured for that customer, which in turn feeds into how partner determination and downstream processing behave.

A Sold-to Party account group like the E001 example in this guide typically needs fuller master data than, say, a Ship-to Party that mainly needs an address and delivery-related fields. This is exactly the kind of distinction that justifies creating separate account groups in the first place - if every customer, regardless of the partner function it primarily plays, were forced into a single generic account group, the resulting screen layout would either be too sparse for Sold-to Parties or unnecessarily heavy for simpler Ship-to Party records.

📋 Common Customer Account Group Categories Across Implementations

While every project's exact codes differ, the same handful of underlying customer categories tend to recur across most SAP SD implementations. Recognizing these common patterns can help when deciding whether a new project genuinely needs a custom account group, or whether an existing standard one already fits.

A project may choose to combine several of these roles into a single account group, or split them out individually, entirely depending on how distinctly the business needs each category tracked and reported on.

✅ Validating the New Account Group Before Go-Live

Once the new account group is created and saved, it's worth running through a short validation checklist before considering it ready for use. Create a test customer (XD01) under the new group and confirm the screen presents the expected fields with the correct required, optional, display, and suppressed settings. Confirm the customer number assigned falls within the expected number range for that group. Create a test sales order for the new customer, using it as the Sold-to Party, and confirm partner determination and downstream processing behave as expected. Finally, review the account group's description and code one more time with the project team to confirm they're clear and consistent with the broader naming convention.

Skipping this validation step is one of the more common reasons a newly created account group causes confusion during the early weeks of customer data migration - usually a number range that wasn't reviewed carefully, or a field status setting that doesn't quite fit how the business actually needs that customer category maintained.

📱 This Configuration in SAP S/4HANA

Creating a customer account group via OBD2 works largely the same way in SAP S/4HANA as in classic ECC, since account groups remain a foundational element of customer master data structure. As with the related screen layout configuration, S/4HANA's move toward Business Partner (BP) as the leading object for customer and vendor master data means account group configuration may be complemented by, or partially migrated into, corresponding BP grouping and role configuration depending on the specific implementation. The underlying decision - creating a distinct category for a genuinely different type of customer, with its own number range and field requirements - remains conceptually the same regardless of which object model the landscape uses.

📋 Related SAP Transactions

🎓 Interview-Style Questions and Answers

Q: Is creating a new customer account group a common or rare configuration task?
It's genuinely project-specific - many implementations rely largely on SAP's standard account groups, while others create several custom ones to reflect distinct customer categories the business needs to track and process differently.

Q: What is the practical difference between Sold-to Party and Ship-to Party as account group categories?
Sold-to Party represents the customer who places the order and typically needs fuller commercial master data, while Ship-to Party represents where goods are delivered and often needs a lighter, delivery-focused set of fields - which is why they're commonly modeled as separate account groups.

Q: Why is it worth agreeing on a naming convention before creating multiple account groups?
Without one, a landscape can end up with several account groups that overlap in purpose but have inconsistent, unclear codes, making it harder for anyone other than the original consultant to understand the customer master structure later.

Q: What's the risk of using SAP's standard demo account groups for live production data?
Demo account groups are configured for illustrative purposes and may not reflect the number ranges, field requirements, or naming that a live business actually needs, which is why most implementations create dedicated, project-specific account groups instead.

📚 Quick Glossary of Terms Used in This Guide

• Customer Account Group: A classification for customer master records that determines screen layout, number range, and certain control settings.
• Sold-to Party: The standard SD partner function representing the customer who places the order.
• Ship-to Party: The standard SD partner function representing where goods are physically delivered.
• Bill-to Party: The standard SD partner function representing who receives the invoice.
• Payer: The standard SD partner function representing who is responsible for settling payment.
• Number Range: The interval of account numbers a given account group draws from, assigned either internally by the system or externally by the user.

📝 Naming and Governance for New Account Groups

Because account group creation genuinely shapes how customer data is structured for the life of a system, most organizations treat it as a decision requiring sign-off from both the FI and SD teams, rather than a routine configuration task any single consultant completes independently. This is particularly true for project-specific groups, like the E001 Sold-to Party example in this guide, where the code and category reflect a decision unique to that implementation rather than a universal SAP standard.

Documentation matters here for the same reason it does throughout the enterprise structure - a configuration workbook recording exactly which account groups exist, what customer category each represents, and why it was created separately from the standard groups, makes the customer master landscape far easier to understand for anyone joining the project later, or troubleshooting an issue long after go-live.

🎯 Conclusion

Creating a new customer account group in OBD2 is a project-specific decision that shapes how a distinct customer category - like the Sold-to Party example, E001, covered in this guide - is structured, numbered, and maintained for the life of the system. Confirming the business genuinely needs a dedicated group, choosing a code that fits an established naming convention, and reviewing both the number range and field status carefully afterward are what separate a well-planned account group from one that quietly adds confusion to the customer master landscape. Keep this guide handy the next time your project needs to establish a genuinely new customer category from the ground up.