• Home
  • About Me
  • Contact Me
  • Downloads
  • White Papers
  • Web Sites
  • Post List
  • Articles
  • FAQ

Olof Simren - Microsoft Dynamics NAV & 365 Business Central Blog

  • Home
  • About Me
  • Contact Me
  • Downloads
  • White Papers
  • Web Sites
  • Post List
  • Articles
  • FAQ

Bill-to vs. Sell-to Customer

April 17, 2014 Posted by Olof Simren Sales 7 Comments

This is an old but still relevant topic; on sales documents (quotes, orders, invoices, return orders, etc.) in Microsoft Dynamics NAV you have the option to specify a separate bill-to customer. The bill-to customer is obviously who gets the invoice and where the accounts receivables end up, while the sell-to customer is who you are selling to.

Having a separate bill-to for some customers is a quite common requirement. In addition to the sell-to and bill-to customer there is also a ship-to address that is used to specify where the shipment is going.

There are some things that you need to be aware of when implementing this, I have seen people struggling with this many times and I thought it would be worth blogging about it (even if it is nothing new).

Below are some of the things that you need to know.

We will use a sales order with customer 10000 as the sell-to customer and customer 20000 as the bill-to customer in the examples.

SalesOrder

Dimensions

The dimensions inserted onto the sales document are from the bill-to customer. It is a very common mistake to define default dimensions on the sell-to customers and then expect them to be inserted onto the documents.

Let say we want to report sales by region and for this we define a REGION dimension with the values equal to the states in the US. We then set a default REGION dimension value on all customers according to what state they are in. In this case it is important to know that if a sell-to customer is in a different state compared to the bill-to customer, then the sales report will show values based on where it was invoiced to. Sometimes this is wanted, sometimes this is not wanted.

SalesOrderDimensions

If this is not wanted, then a way around this could for example be to have the users enter the REGION dimension value on each order manually (by leaving the dimension value blank on the default dimension for the bill-to customer), or to do a modification to have Dynamics NAV to insert dimensions from the sell-to instead (or maybe even based on the ship-to).

Prices and Discounts

All prices and discounts are based on the bill-to customer. This in most cases makes sense, so when you setup your price lists and discounts don’t set them up against the sell-to it will have no affect. I have seen this in many places and this is another common mistake.

Item Ledger and Value Entries

The item ledger entries and value entries created during posting are a bit interesting. The item ledger entry gets the Source No. according to the sell-to customer while the value entry gets the Source No. according to the bill-to customer.

ItemLedgerEntries

ValueEntries

Historically this has changed from version to version as well. A bit strange, but I guess the way it is now in NAV 2013 makes sense (as long as you know it when running reports, filtering, etc.). It would have been nice to have both in both places.

Customer Ledger Entries

The customer ledger entries are obviously created against the bill-to customer, but it also contains the sell-to customer number in the Sell-to Customer No. field. Nice!

CustomerLedgerEntries

Analysis View Entries

The analysis view entries has the bill-to customer number as the Source No., this makes sense since the dimensions are based on the bill-to customer.

AnalysisViewEntries

Reports

Most of the canned reports, like the Customer Top 10, Customer/Item Statistics, Customer – Order Summary, etc. are based on the bill-to customer. Although there are some exceptions, like the Item Sales by Customer, that are based on the sell-to customer.

Some of the reports are created using the flowfields in the customer table (which are mostly the bill-to customer), some of the reports are created based on the value entries (which is the bill-to customers) and some of the reports are created based on the item ledger entries (which is the sell-to customers). Therefor a bit of a mixture.

Conclusion

Of the above mentioned things the Prices and Dimensions are by far the most common source of discussions when implementing Dynamics NAV. A couple of times I have had to change it so that the dimensions and prices are based on the sell-to customer instead, this have turned out to be quite a small and doable change.

Share this:

  • Click to share on Facebook (Opens in new window) Facebook
  • Click to share on X (Opens in new window) X

Related


Discover more from Olof Simren - Microsoft Dynamics NAV & 365 Business Central Blog

Subscribe to get the latest posts sent to your email.

Tags: Bill-toCustomerSell-to
7 Comments
Share
3

About Olof Simren

I am a Microsoft Dynamics NAV and 365 Business Central Expert, I started implementing Microsoft Dynamics NAV in 2002, back then it was called Navision Attain. Throughout the years there has been many exciting implementations in different parts of the world, all of them with different challenges but with one common theme; manufacturing. As a consultant, I bring over 20 years of experience in implementing Microsoft Dynamics NAV and 365 Business Central within manufacturing and distribution companies. The services I offer includes project management, consultation, development and training. Feel free to contact me if you need help with anything related to Microsoft Dynamics NAV or 365 Business Central. I work through my company Naviona where I team up with other skilled Microsoft Dynamics NAV and 365 Business Central Experts.

You also might be interested in

Functionality Improvements in NAV 2015

Oct 14, 2014

Microsoft Dynamics NAV 2015 was released a couple of weeks[...]

Connect a Customer with a Vendor

Jun 19, 2014

Sometimes a customer is also a vendor and sometimes a[...]

Sales Quote without Customer

Jul 11, 2016

Do you know that you can create sales quotes without[...]

7 Comments

Leave your reply.
  • Tomi Koskela
    · Reply

    May 10, 2016 at 2:33 AM

    Very useful post, thank you!

  • Leana Shulda
    · Reply

    October 20, 2016 at 3:22 PM

    HI there – your blog has been very helpful on many fronts. I have a question as it relates to this information in NAV 2016. Does everything in your blog still apply in the 2016 version? We are implementing NAV 2016 and struggling with the Customer Bill To/Sell To setup because we pay outside sales rep based on where something is shipped to and have a number of customers with many Shipping Addresses.

    We were going to utilize the Territory code with values of our various rep groups in the Sell-To section as a default and were hoping we could tie the rep group at the shipping address level. We could have one customer who has multiple rep groups involved depending on where product ships. The Shipping Addresses does not have the Territory code at that level (I don’t think) so we were then thinking we could have the multiple shipping addresses be entered as a separate customer using the Sell-To as each shipping address with the same Bill-To address. Then we could use the Territory code represented for the Sell-To (shipping address). I also don’t see dimensions at the Shipping Address level.

    We would then need to run reports based on paid invoices (we don’t pay commission until the customer pays us) pulling by Territory to know how much we owe each rep group.

    Another point here but haven’t tested yet is how the customer payment is applied – will it all show up in the Bill-To? I’m thinking so but didn’t want to create issues on the back-end with applying payments.

    Thanks in advance.

    • Olof Simren
      · Reply

      Author
      October 20, 2016 at 10:38 PM

      Hi Leana,
      Thank you for your comments.
      I believe that all the things I have written on this blog also applies to the 2016 version.
      In your case, I would recommend doing a modification that adds default dimensions to the ship-tos, this is very useful for a number of reasons and a common modification.

      Yes, the AR all ends up on the bill-to, so that’s the entity that you collect the payment from.

      /Olof

  • Joe W
    · Reply

    September 17, 2017 at 5:07 AM

    Interesting and useful post thanks.
    We have a number of clients who utilise a third party finance provider, so we have to send invoices to this completely different company. This “bill-to customer” isn’t really a customer at all, but we have to send the client’s invoice there so it gets paid. It sounds like the way that NAV will use the dimensions of the bill-to customer for accounts reports doesn’t seem ideal for this scenario?

    • Olof Simren
      · Reply

      Author
      September 18, 2017 at 10:15 AM

      Hi Joe,
      Agree, the intention of the bill-to functionality is different from what you are describing.

      /Olof

    • Georges W
      · Reply

      October 3, 2020 at 10:41 AM

      Thank you for the interesting post.
      This is a very interesting scenario, that we observe more and more among Customers nowadays. Our main Customer is using a third party finance provider, that requires a specific bill-to address, different from physical address. We are not talking about different bill-to Customer ID and modification of postings. Simply different address e-mail fields to be used only to send/print Sales Invoices. Does Dynamics 365BC offers a simple solution to this more and more common scenario, without having to go through development ? Thanks for your input.

  • Bjarke Alling
    · Reply

    February 4, 2018 at 6:23 AM

    Hi Olof,

    Thanks for some great blog posts.
    We are relying heavily on the functionality of sell-to and bill-to. Our business is software distribution with end-users and resellers. Classic 2 tier model. The NAV process works great for us.

    Now we run into the issue that we need to add an additional sub distribution part into the equation. We now have a 3 tier model.
    I was looking at simply just and one more layer by having the end-user (sell-to account 1000) connected to the reseller (bill-to account 2000) and then connected one more time to the sub-distributer account. As I see the only place to change default NAV code is in the sales invoice process. Making sure that the code travels the hierarchy of sell-to > bill-to1 > bill-to2. The stops when and pick the account that has no bill-to value set. Use the account and run the invoice code.
    Have you ever seen anyone doing this and would you believe the model could work?

    Thank you in advanvce

    /Bjarke

Leave a Reply

Your email is safe with us.
Cancel Reply

My Dynamics NAV Partner

Naviona, LLC

Developers Wanted

Naviona is looking for NAV/BC developers. Let me know if you want to work with the best (instead of the rest :-)).

Categories

  • Assembly (3)
  • Development (31)
  • Finance (14)
  • General (26)
  • Inventory (22)
  • Manufacturing (34)
  • Miscellaneous (25)
  • Purchase (9)
  • Sales (11)
  • Warehouse (7)

Tags

.net Add-in Assembly Assembly BOM CAL Capacity Components Consumption Contact Costs Customer Development Dimensions Excel Finance Flushing General Ledger Inventory Item Items Lot Size Low-Level Code MRP NAV 2015 NAV 2016 Output PDF Planning Production Production BOM Production Orders Purchase Orders Receipts Reporting Reports Role Center Routing Sales Sales Order Sales Orders Stockkeeping Unit Subcontracting Task List Warehouse Warehouse Shipment

Recent Posts

  • XML Buffer and CSV Buffer Tables
  • Functionality Improvements in NAV 2017
  • Reversing Production Output and Consumption
  • Return Merchandise Authorization (RMA)
  • Sales Quote without Customer
  • Parallel Routings
  • Add Fields to the Item Tracking Lines
  • Field Level Security using Events in Dynamics NAV 2016
  • Schedule MRP
  • Activate WMS Functionality for Existing Location

Categories

  • Assembly
  • Development
  • Finance
  • General
  • Inventory
  • Manufacturing
  • Miscellaneous
  • Purchase
  • Sales
  • Warehouse

Contact Us

We're currently offline. Send us an email and we'll get back to you, asap.

Send Message

Categories

  • Assembly (3)
  • Development (31)
  • Finance (14)
  • General (26)
  • Inventory (22)
  • Manufacturing (34)
  • Miscellaneous (25)
  • Purchase (9)
  • Sales (11)
  • Warehouse (7)

Tags

.net Add-in Assembly Assembly BOM CAL Capacity Components Consumption Contact Costs Customer Development Dimensions Excel Finance Flushing General Ledger Inventory Item Items Lot Size Low-Level Code MRP NAV 2015 NAV 2016 Output PDF Planning Production Production BOM Production Orders Purchase Orders Receipts Reporting Reports Role Center Routing Sales Sales Order Sales Orders Stockkeeping Unit Subcontracting Task List Warehouse Warehouse Shipment

Recent Posts

  • XML Buffer and CSV Buffer Tables
  • Functionality Improvements in NAV 2017
  • Reversing Production Output and Consumption
  • Return Merchandise Authorization (RMA)
  • Sales Quote without Customer
  • Parallel Routings
  • Add Fields to the Item Tracking Lines
  • Field Level Security using Events in Dynamics NAV 2016
  • Schedule MRP
  • Activate WMS Functionality for Existing Location

Recent Comments

  • Isabel de los Santos on Production Lot Sizes
  • Abdelatif EL HANI on Reversing Production Output and Consumption
  • Roshan on Processing of Receipts
  • kuldeep Nama on Subcontracting Part 1: The Basics
  • Janine on Flushing Methods
  • Nathalie on Activate WMS Functionality for Existing Location
  • Georges W on Bill-to vs. Sell-to Customer
  • Richard L on Subcontracting Part 4: Warehouse Receipts

© 2025 · Olof Simren

  • Home
  • About Me
  • Contact Me
  • Downloads
  • White Papers
  • Web Sites
  • Post List
  • Articles
  • FAQ
Prev Next