One Company, Two Roles: Customer and Vendor Setup and Inquiry in One Place in D365

In manufacturing, it is not unusual to sell by-products back to the company that supplies your raw materials. The other party is a single company, but in the ERP it plays two roles: a vendor for purchasing and a customer for sales.

Microsoft Dynamics 365 Finance & Operations (D365 F&O) keeps customers and vendors as separate accounts. The address book lets them share common details such as the company name, address and contacts, but registering and maintaining customers and vendors are still separate tasks, split by role.

Finance runs into the same split. To review one partner's receivables (AR) and payables (AP) together at month end, someone has to look up customer transactions and vendor transactions separately and compare them.

To cut down this repeated work, JGS Consulting built two features into the JGS Agile Package:

• Business partner registration: register the customer and the vendor together in a single entry.
• Business partner transaction inquiry: see both sides of the same partner's transactions in one list.

This post looks at how far standard D365 goes, what JGS extended, and how day-to-day work changes.

Same partner, so why is the work done twice?

Three frustrations come up again and again in master data and finance work:

• A company that is both customer and vendor still needs each account registered and maintained on its own.
• Customer and vendor accounts can follow different numbering schemes, so staff have to work out separately which accounts belong together.
• Comparing customer and vendor transactions side by side is not possible on the usual standard pages; each side has to be looked up on its own.

Companies in Korea have one more requirement: the business registration number. It has 10 digits, and the last one is a check digit calculated from the others. Checking only that a number has 10 digits will not catch every typing error.

A valid check digit, however, does not mean the business is actually registered or still operating. Validating the number format and looking up the business status with Korea's National Tax Service are two different tasks.

JGS noticed that these registration, validation and inquiry needs came back on project after project. Rather than rebuilding the same features for every customer, we packaged them once for reuse.

How far does standard D365 go?

Before building anything, JGS started with what standard D365 already offers. D365 already has a structure for linking customers and vendors. The main one is the Global Address Book: a single party can hold both the customer and the vendor role and share its name, address and contact details.

Account numbering for customers and vendors can be set up with number sequences. Registration IDs can hold identifiers such as the business registration number, with settings for format and uniqueness.

We used these standard features as far as they would go. But having a feature in standard is not the same as giving staff the workflow they actually need. The requirements we reviewed went beyond assigning two roles to one party:

• Enter the common details on one page and create the customer and vendor accounts together
• Give both accounts the same code, following the company's own rules
• Validate the Korean business registration number check digit at the point of entry
• Turn duplicate checks on or off separately for customers and vendors
• Keep the party record and the role-specific accounts consistent when they are created

After checking whether the standard registration steps and settings could meet these requirements, we concluded that the combined workflow we defined needed additional development.

Transaction inquiry showed a similar gap. D365 has inquiries for customer transactions, vendor transactions and voucher transactions, plus reversal functions by transaction type, and reports or custom development can pull this information together. What JGS set out to build is not a report that simply prints the data, but a working page that lists customer and vendor transactions together and links through to the standard transaction pages.

For registration, we compared 12 detailed requirement elements against standard functionality. Three were met by standard features and two were classed as partially met. The remaining elements are tracked by the scope of additional development and detailed review they need.

From registration to inquiry: how the work changes

What does the workflow look like with the business partner features in place? Take a manufacturer registering a partner that is both a customer and a vendor.

Registration first. On the business partner registration page, the user enters common details such as the company name and address, and selects the customer and vendor roles. The 10-digit format and check digit of the business registration number are validated during entry, and duplicate checks can be switched on or off by role.

The same business partner code is then applied to both the customer and the vendor account, and the party record and each role's account details are created.

The key point is that customer and vendor accounting are not merged. Receivables and payables keep their own standard account structures; only the common work needed for registration and inquiry is brought together. The processing is also designed so that an error during registration does not leave only part of the data saved.

Transaction inquiry changes too. Before, the customer and vendor transactions for the same partner had to be looked up on separate pages. With the JGS Agile Package, both sides appear in one list based on the business partner code.

Users can see amounts, exchange rates and settlement status, and when they need detail, move straight to the linked standard customer or vendor transaction page or the voucher transactions page. Where a transaction needs to be reversed, the design uses the standard D365 reversal process for that transaction type and status.

In short, we are not inventing a new way to post accounting entries. We keep D365's standard transaction processing and simplify how people find and check the information.

What we expect to gain

1. Less repeated registration work. Common details for the same company no longer have to be entered in several registration steps, customer and vendor accounts are created in one workflow, and both accounts are linked under one business partner code.

2. More accurate master data. The goal is to validate the registration number format and check digit at entry and, with the configured duplicate-check rules, reduce wrong data and duplicate registrations.

3. Simpler inquiry and reconciliation. Seeing one partner's customer and vendor transactions in the same list, with links to the standard pages, cuts down on switching between screens.

There is also a reuse benefit for implementation projects. Items that vary by company, such as the business partner code scheme and whether duplicate checks are on, are managed through number sequences and parameters wherever possible. Within those settings, customer-specific needs can be met without writing new code.

The JGS Agile Package is built as extensions, without modifying the standard D365 source code. Adding features on top of standard functionality in this way can help reduce maintenance effort during version updates compared with changing standard code directly. Compatibility reviews and regression testing are still needed for each update.

Where it stands, and what comes next

As of October 15, 2026, business partner registration and business partner transaction inquiry have finished their planned development work and are in testing. It is too early to report results from a real customer environment or final test outcomes. Once testing is complete and verified results are in hand, we will share them with the actual screens.

We expect these features to fit:

• Manufacturers and distributors that both buy from and sell to the same partners
• Companies that want fewer registration-number errors and duplicate partner records
• Finance, AR and AP teams that need to review customer and vendor transactions together

What matters in an ERP implementation is not how many new screens you build. It is how well you reduce the friction people face every day while getting the most out of standard functionality. That is the lens we use to analyze recurring requirements and build reusable features in the JGS Agile Package. We will keep sharing the design intent, the implementation and the test results feature by feature.

If you have similar needs around partner master data in D365 F&O or an upcoming enhancement project, please get in touch: https://jgs.ai.kr/support/contact

JGS Consulting — Designing the future of business.

Korean version https://blog.naver.com/jgsconsulting