With the explosive growth of ecommerce in recent years, there’s no wonder why accounting professionals and business owners are utilizing automation to save time and stay organized. But is your QuickBooks Enterprise ecommerce integration set up for maximum efficiency? Keep scrolling to watch Part 1 of this deep dive into Webgility with Marjorie Adams of Fourlane and learn how to set your preferences for everything from setting up order groups, directing customers to a web portal, handling returns, matching customer types, and more. Or, read the conversation in its entirety below.
Marjorie Adams, Fourlane: Thanks for joining us this week. I know we talked a couple of months ago about the state of ecommerce, and I had so many emails about this. Everybody was very excited about trying to figure out how to connect their web stores to QuickBooks for automation and making sure that we’re not right. If somebody will do the data entry for you, nobody on our team should have to do the data entry again.
Today we’re going to dive a little bit deeper into Webgility, which is [a software] we talked about a couple of months ago, and go through the setup and preferences. This is going to be a two-part series. We’re going to talk about preferences of how to set up a Webgility store connection. Then, we’re going to go into another one which is more talking about what happens when things change post setup. I’m Marjorie, the CEO of Fourlane, and I’ll be leading the call today. We also are joined today by Zach from Webgility. Zach, thanks for joining us.
Zachary Smith, Webgility: Hi there, Marjorie. Thank you so much for having me.
Marjorie: You want to tell us a little bit about your role at Webgility?
Zach: Yes. At Webgility, I’m called a senior account executive. Definitely work with clients upfront to make sure that we understand requirements and that our solution is actually going to do what they need it to.
Marjorie: I love it. Awesome. How long have you been working with Webgility? I actually don’t know the answer to that question.
Zach: I’ve been with Webgility for about a year now.
Marjorie: Oh, wow. Gosh, how do you have so much knowledge? Oh my gosh. I suppose it’s the same as it is here at Fourlane—the volume of customers that you’ve talked to makes you understand all those situations even deeper, I assume.
Zach: Yes. I’ve got to tip a major bill of my cap to our fantastic client base. Quite frankly they are the ones that have driven all of my learning. I’m just fortunate enough to work with really smart people who are running businesses.
Marjorie: I feel you there. That’s the same as me. When we tell people who come on board here at Fourlane, we say like, we learn the most from our clients. So getting in on that client call, getting in that exposure, where we’re going to see them. As you guys know, we’re going to dive into the product for most of today. Just as a reminder, if you missed any part of this, you want to come back and watch us, you can go to the YouTube channel and see that. It’ll be posted shortly. We also have our Fourlane QuickBooks Enterprise group where we’re taking surveys and things like that. If you want to join that, feel free.
Well, we’re going to talk about posting settings. I want to make sure that everybody understands the difference between this week and next week. [Today] we’re talking about setup. When you go into QuickBooks, we go into our QuickBooks file and we go into Preferences, Edit and Preferences, and we set up everything in the beginning.
That’s something that we do. Similar thing as when you go in and set up Webgility in the beginning, we have to make a whole bunch of choices. Why would we do it this way? When would we do it that way? We’re going to talk about a lot of that today.
I’m going to go ahead and turn screen control over to Zach so we can go inside of Webgility.
Initial Setup and Posting Settings
Zach: All right. Thank you, Marjorie. When you start a Webgility account, a number of things are going to happen, but one of the most important is configuring the solution to do what you would like it to in an automated fashion. I think the slide was a pretty good direction as far as how to best walk through the most important settings. There’s a number of optional settings that we are happy to jump into at any time, but ultimately today we’re going to try to give the most thorough overview possible that’s not being explored through the lens of a specific client’s needs.
When we look at order posting, there’s really a couple primary things we’re going to try to differentiate. First and foremost in our list of preferences is whether you’re going to post individually or in groups. Marjorie can speak to this much more in-depth than I can as a QuickBooks expert, but there are definite reasons that we would potentially want to choose one or the other. Do you want to dive into that a little bit, Marjorie?
Marjorie: Yes. Sure. First of all, everybody knows if you work with Fourlane, we try as much as possible to make sure that people can stay inside of QuickBooks Enterprise. One of the major drivers that people have come to us before and say, “I can’t use QuickBooks anymore,” is because of the volume of transactions. Hopefully, we all have a web store where we’re processing thousands of orders a day. That would be the most ideal situation, but the fact that you can post orders in groups allows you to cut down.
[You will] still have the image inventory updated, still have the pricing, the sales tax, all these things, but you can do several orders on one transaction posting, which keeps that transaction count down. I have a couple of clients that we’ve done this for. Oftentimes, I don’t usually recommend my clients to do this daily. I don’t know about you, Zach, do you? Which one do you usually choose with customers, or what do you find customers choose the most?
Zach: The most common for consolidated or posting in groups is to post by settlement report period for marketplaces like Amazon. Having said that, I’ve seen a wide variety. Like Amazon is biweekly, and we can post with the settlement report period. However, I’d say the most common is probably weekly. Now, there are reasons that you would want to post more frequently.
For example, if you have concerns about overselling, you have a robust in person, your B2B sales people are entering orders directly into QuickBooks. There are reasons that a more frequent posting might make sense if we need to relieve that inventory in closer to real-time. I would say it varies wildly by client. The most would probably be daily or weekly if we’re going to go the consolidated or group posting approach.
Marjorie: I think I’ve seen when people are doing inventory tracking, as you were saying, daily is a lot. You have to be more on top of your inventory, make sure that you’re not having any inventory issues especially if your inventory turnover is a shorter period of time. Where I’ve seen people who are resellers of other people’s products, they actually don’t touch the product at all, so they don’t have to maintain inventory at all then I’ll see that more weekly or it’s very rare that I see monthly, but yes, I agree.
Zach: That’s been extremely rare. I think I’ve seen that maybe once. I would agree with you 100%, that is well stated.
Marjorie: It’s a great way. Still, a lot of the times when people are doing things like this, they are tracking the details in a CRM system somewhere else. Maybe Shopify, which is the store we’re looking at here, connects to Salesforce, or whatever it is that you have out there. The detailed transactions are under the account there. The details of the orders are under the customer account. One’s last time the customer ordered, how many times has the customer ordered, that’s maintained in a different database. If you are keeping track of that data in a different database, you do not have to keep track of that data in QuickBooks. It’s great that we have this as an option.
Zach: That’s a really good call out too in terms of like if you have a CRM and you don’t need to use QuickBooks as your “customer system of record” that would be a really good scenario within which group postings would make sense to “standard customer” which we’ll cover here in just a moment.
Marjorie: I like it.
Zach: Now, once we’ve determined whether we’re going to post individually or in groups, we’re going to try to differentiate how it is we should post. Now, to be noted for those of you that sell on multiple marketplaces or channels, each of your unique places you sell can be posted differently if needed. If you have a unique Shopify store for wholesale versus direct to consumer, maybe we’re posting invoices or sales orders on the wholesale side, [and] sales receipts on the direct to consumer side, but within one channel, we can also differentiate how we post by order status or payment method.
I’m putting myself at risk of going too deep down a rabbit hole here. One thing we would like to be cognizant of is just this idea that you’re not trapped. You don’t have to post just one way. I know many of the connectors in this space, once you’ve set it up to do one thing, it cannot do another, but that is a nice benefit to this solution is that you can differentiate how you post and you can do so within the channel or just simply by the different unique places that you sell.
Marjorie: I actually wasn’t aware that you could do that by store. That’s amazing because we do have a lot of clients who have multiple brands. You have, as you mentioned, maybe the wholesale account. We have clients that come to us a lot and they say, “I want to have a customer portal where my customers can go place orders in this portal, but it’s not public for everyone to see the pricing.” When customers come to us and tell us that situation, we always say, “Well, why don’t we set up a web store because a web store has all of these features that you’re asking for and you don’t have to build something custom.”
Zach: We hear the pain points of, “We’re getting way too many phone calls and emails.” It’s like okay, well, one really efficient way to not try to eliminate some of that effort would certainly be to direct these folks to some sort of a web portal. Sometimes it’s just as simple as, hey, if somebody checks out, and their “checkout method” is net terms, well, we ought to post an invoice that matches those net terms. If somebody pays with a credit card, we probably ought to post a receipt or we need to reinforce unique classes by transaction type. There’s a number of reasons that we might do this, but ultimately, it’s going to vary wildly by client.
Sales Receipts vs Sales Orders
Marjorie: Okay. We can go in and we can choose different templates because that also matters if for any reason we’re posting or printing transactions out of QuickBooks, you can have different logos on different templates. I mean, there’s so many different ways that you can utilize those. For us and our clients, most of the time, we’re having the fulfillment happening out of QuickBooks and so when we’re doing fulfillment out of QuickBooks, we usually like using a sales order. If you guys have seen workflows we talked about before.
Estimate sales order invoice is the best workflow because it affects quantity available before quantity on hand for us, and that’s really important with inventory tracking. We’re also seeing sales receipts a lot of times and then basically on a sales receipt. Since you’re in QuickBooks Enterprise, it’ll have statuses. It’ll create a custom field for status of sales receipt, either as a header at the line level in order to track if we have done fulfillment for this line or not. Have you seen any situations where people tend to head towards sales receipts more than sales orders?
Zach: It seems to be such a personal preference. I have a number of people where in my limited understanding of accounting, it seems like a sales receipt would be the right way to go but instead, they want to post invoices marked as paid, just because that’s what they’re comfortable with. Ultimately, we’re trying to reinforce and make people more efficient as opposed to making them redo every single process that they have internally. I have seen a proclivity toward sales receipts anytime that something is paid prior to us posting it, but having said that, if your internal workflows [are established] or you guys work off of invoices, that’s certainly something we can reinforce as well.
Marjorie: The difference between a sales receipt when it comes to QuickBooks is that a sales receipt is a singular transaction—one and done. A sales order to an invoice to a payment because those three things would have to happen or three separate transactions. Invoice to a payment are two separate transactions. A lot of times it’s also a timing issue. A sales receipt is if we’re doing performance the same day. A sales receipt is generally okay, if we’re not doing performance the same day, then most likely we need to do a sales order because first of all, you should not relieve inventory immediately if you’re not actually removing inventory immediately. Then also it helps us track that fulfillment, what has been fulfilled or not.
Zach: That is certainly the hope. Back to what we said upfront. I learned more from our clients and I could never hope to learn somewhere else. If this is how you want to do it, we certainly want to understand why to make sure we’re not sending you down an awful path. That hit the nail on the head. Flexibility is key here.
Zach: You’re bringing up a good point there too because we can skip one of those multiple steps included if we need to create a payment with the sales order, or we need to mark an invoice as paid. We can do our best to trim out as many manual steps as possible, but you’re absolutely right. Eyes wide open on the fact that if you post a sales order, you’re likely going to generate an invoice and then close that invoice. Thus resulting in those three separate transactions.
Marjorie: Awareness is key, but the fact that you have choices is amazing.
Marjorie: I like it. What about returns? What happens if somebody returns? Where do we go to our settings around that?
Handling Ecommerce Returns
Zach: By and large, that’s going to result in the creation of a credit memo. There’s a ton of separate tabs in here. I think we can walk through these. Different tabs will appear based on what other related transactions we’re going to be trying to reinforce. There are some transaction settings that are largely involved with the basics of posting a sales order invoice, sales receipt, or estimate. Many of these have to deal with where information lands when it gets to QuickBooks.
For example, if we’re using QuickBooks IDs to drive transaction numbering, what do we want to do with this hypothetical, our Shopify transaction IDs? We want to drop those into Other or Payment Memos so that you can easily reference these transactions by this other ID if necessary. Customer ABC calls and asks, “Hey, what happened with my Shopify order number 12345?” As long as you know where that landed in QuickBooks, you can easily reference these various transactions by whatever key identifier makes the most sense.
On the credit memo side, essentially what we’re going to do is create these if a return occurs. We also have this question of if a refund occurs, what do we want to do with that? Are we going to void the transaction? Are we going to create a refund check? Are we going to generate a credit memo? There are some optional settings here as far as how we approach this. Again, this goes back to how it is you account for returns and whether or not you want to adjust inventory.
For example, if a return comes through and it is resellable, do we want to add that back into inventory or not? It’s usually as complicated as checking a box. Again, we’re going to try to reinforce what it is that our clients want to do but by and large, I’d say the vast majority of them are going to generate a credit memo if a return occurs.
Marjorie: Right. Credit memo is an AR-type of transaction, so we know that. You can’t do a negative sales receipt. That’s not something that is possible, so put in a credit memo so that we can return that inventory into stock if that’s what we’re choosing to do. Then issue the cash out so that we can add that to our virtual service deposit so we can do accurate cash tracking. Inventory updated. I have seen people [who] don’t think about that. You don’t think about that and your merchant service deposit sometimes does the returns because it’s not always as automatic or the chargebacks or whatever it is.
It is important that we have workflows that we can help with making sure that we can update inventory if we get the inventory back. I have seen some people with these credit memos in Enterprise, of course, and we’ll look at this in a second. In Enterprise, you can track by multiple locations so I have seen people too, who, when they’re trying to make sure that the product is coming back in, they might utilize an alternate location. I’ve seen people do that as well so that they can see what’s not here yet but expected to come in or we also have put statuses on the credit memo as an example.
Zach: Absolutely. Like I said, it’s checking a box as it relates to Webgility, but that insight is just phenomenal. I’m not certain, but what I can tell you for sure is, you would have an option to adjust that inventory or not. Then if you do leverage multiple “inventory locations” for whatever reason, that’s stored under our product settings but that is also something that can be reinforced with Webgility.
Marjorie: I like it. What about purchase orders? How would that play into this?
Zach: This is really the ability for Webgility to generate appeal in QuickBooks. The two most common scenarios within which that occurs is either, A, it’s a dropship type item. So, you’re going to have to issue a PO. Or, B, something has run out of stock, and thus you would like our system to generate a PO. We can either mark items as dropships in Webgility, and thus it will generate a PO. How exactly it does, there’s a number of settings there or we can say if an item runs out of stock, then generate a PO in QuickBooks. You would still send and receive that PO within QuickBooks, but our system would create it for you, trying to at least trim out one of those steps involved with that process.
Marjorie: I guess I like that. The dropship scenario I think is the most common. Inside QuickBooks, a sales order is not linked to a purchase order. We all know that. Fourlane has created a QuickBooks inventory report so that we can link the two in the report to see what’s on a sales order that’s not on a PO. I know we’ve shown this in videos in the past but this is really nice for all those people who do dropshipping and don’t hold on to these items in their own inventory. It’ll auto-create those purchase orders for you so you don’t have to go in and manually do that. That’s just a huge step in automation the first time. This is not only talking about a single point of entry for the order. This is also talking about a single point of entry for the order when we’re going to place that order with our vendor. That’s huge.
Zach: Correct. Usually, it’s going to pull from preferred vendors in QuickBooks. I know in automotive parts, you will have multiple vendors. There’s a reason we’re not just going to send the PO. Generally, people will review those. Yes, it can certainly create them.
Marjorie: Awesome. That’s the same thing where a lot of time, inside of QuickBooks, we’ll set statuses, so that we can review prior to. We’ll add a box, a custom field box that we leave blank when it’s created, and then once we review it, mark it as reviewed, that’s when we would be sending it off to the vendor. Of course now with QuickBooks 2, we have automations of purchase orders, or approval processes, purchase orders size, even further steps that we can take, which we have not shown in the video yet because it just got released, but we should be showing that pretty soon.
Zach: Pins and needles, looking forward to it.
Marjorie: All right, I like it. Anything else that we want to look through in these settings?
Zach: I would like to just throw out the clarifier that we even have optional settings to remove the pound symbol from the beginning of Shopify transaction IDs if they need to live in a field that doesn’t accept special characters. While we did a beautiful deep dive here, I just want to open the door for other questions and concerns because there’s a lot that we can accomplish with the myriad settings available to us.
Auto Build Assemblies in QuickBooks
Marjorie: One of the ones, I forgot about this one too, because this is something that we have, people ask all the time, is around the build assembly, just this build product before creating. Can you talk a little bit about that as well since there are so many manufacturing clients that are on this call?
Zach: Yes. Essentially, what it’s going to do is from an inventory perspective, prior to posting the transaction, regardless of how we’ve set it to post, what’s going to happen is it’s just going to auto-build any assembly items that you’ve created in your QuickBooks. This comes into play too when we’re reflecting inventory levels, like we reflect the available quantity of assembly items as a reflection of the components required to make it.
This is just the idea that we can actually auto-build those assemblies prior to posting a transaction or as we post the transaction into QuickBooks too, again, just in the interest of saving time. There’s some human error involved here. I’ve fumbled my way through creating enough assembly items that I know that I’ve messed that up about 90% of it. It’s just this idea that you can tell our system to auto-build assemblies, either as or prior to it posting the transaction that it took in from the ecommerce site.
Marjorie: Again, it’s another step, just like creating the purchase order. It’s another step, another transaction that can be automated, prior to. I also like that it has the move order to an error tab if the assembly cannot be built. If we’re short on components, assembly cannot be completed, they’ll move it to an error tab, so you can figure out what’s going on with that, because that’s one of the hardest things when it comes to people asking for automation of build assemblies, is, well, who wins, first of all, there’s multiple orders, but then also, what do we do if we can’t build on?
That’s a great step. If you’re not doing it this way, where you have the build happening, what a lot of clients have is they sell the assembly, so the sales order goes in or the sales receipt goes in, the assembly is sold to the negative, and then we go in after the fact, even if it’s on the same day. We talked about this, the first post inside QuickBooks; even if we go in after the fact and we post that build assembly today, the created date would be different.
We would see that sales receipt first. The sales receipt was created first, but the posting transaction date is today, so it’ll think that it went negative. The fact that it will do this before creating the order is a huge step in making sure we don’t have those negative inventory items. So really, really awesome that we have that as a preference.
Zach: Yes. You bring up such a good point because if we’re not going to build it before, then we would likely want the build assembly date to be the current date as opposed to the order date, depending on if there’s any lag occurring within QuickBooks. You just really eloquently described something I would have fumbled over for five minutes if I was trying to do so.
Marjorie: This is also a good reason to do sales orders.
Zach: Exactly.
Marjorie: I like it. All these steps of automation that we can take into account here, I like it. I’ve also had some clients, by the way, who don’t have web stores, so again, we talked about customer stores a little bit before, but they actually use web stores to take advantage of some of these automations. Their sales reps, they don’t want to be placing things inside of QuickBooks, so they will use a web store.
You can put things in an estimate status in a web store. You can move it forward into the order once you’re ready to move forward. They can take advantage of some of these automations by using web store to Webgility to QuickBooks, instead of having to build customizations on top of QuickBooks. We are definitely pointing customers in that direction before they take advantage of what exists out there—before recreating the wheel.
Zach: In the last six months, a ton of circumstances within which, “Hey, our sales team is now remote for the first time.” Shopify is accessible no matter where you are as long as you have an internet connection, whereas, “Do you have a remote desktop on your phone?” “How are you going to get into the device where QuickBooks Enterprise lives?” This is just another way to make things more accessible for your sales team, should they not be in a circumstance where they can get directly into QuickBooks.
Marjorie: I love it. Awesome. Let’s go to the Products tab.
Product Mapping Between Webgility and QuickBooks Enterprise
Zach: We’re good. Luckily, products are pretty darn efficient. Because from a product setting standpoint, there’s going to be a lot we’re going to want to discuss as it relates to automation, but from a settings perspective, and just getting this to a place where it’s functional, the most important thing we’re going to try to do is identify what it is the matching criteria is going to be. Right when you start a Webgility account, it downloads all your products from both QuickBooks and whatever ecommerce we’re linked to and it’s going to try to find as many matches as it can.
The other setting that exists here is what are we going to do if an order comes through for something our system does not recognize? There are four options. You guys can all read the screen here. Essentially, we can tell our solution to prompt you to figure out what to do with it. It came through, so is this actually something that already exists in QuickBooks and we just simply need to map it, or is this something we should create?
You can have the system automatically create new products. I would say that is not particularly common. For people that have a lot of custom goods, or they sell a lot of miscellaneous parts, things of that nature, sometimes people will post items to a standard product called miscellaneous online sale or something to that effect, or the last one, incredibly anticlimactic, but the other option would just be to simply flag the order as an error, and you can figure out what to do with it at that stage.
Marjorie: What to do with it? I’ve seen that a lot of times. Of course, if we’re doing the user’s product instead, we would be using a non-inventory part, or sometimes a service charge or something like that, definitely not an inventory part or a build assembly item because we don’t want it to be throwing quantities negative all over the place.
Zach: It would almost always be a non-inventory item. I have a client who does an incredible volume of custom saddles. It’s awesome, but the creation process of this, thank goodness, they were nice enough to share with me, it takes a lot to build a custom saddle. Each time they do this, they don’t necessarily create a brand new custom saddle with turquoise lining on the left side. They don’t necessarily create that item in QuickBooks. They have a standard non-inventory item called a custom saddle.
We’re going to map the online SKU to that “non-inventory custom saddle item” and that’s how it’s going to function. Or in a circumstance where we have 30,000 automotive parts listed on our ecommerce site, most of them live in QuickBooks. Some of them don’t, but we know that for any of those catch-alls, we’re just going to post it to a non-inventory item called miscellaneous part. I’ve seen some cool scenarios within which people will use this option, but it’s not particularly prevalent.
Marjorie: It gives control, and we can make changes to this as well, where maybe in the beginning, as you’re starting to gain competence in Webgility, syncing from your web store, it takes some time for people—it takes some time for us accountants, we’re a little bit control freaks over here—to get the confidence of the system doing what it says it’s going to do. Maybe we start out with a “map it and let me see” [mindset] or flag it with an error, and then once we’re feeling comfortable and confident in how the system’s flowing, we can switch it to automatically create the new product if that’s where we’re at.
Zach: With the incredible agility of our clients to deal with everything that’s occurred in the last two years from a commerce standpoint, yes, there could be situations within which you don’t sell any used goods today, but then we have enough of them at some stage in the game that it makes sense to prop up an eBay store, and it’s impossible to track inventory for all of these unique items that we are now selling on more of a marketplace for used goods. As needs evolve, this should be a solution that can flex with you as you continue to make the appropriate agile move to continue killing it at commerce.
Marjorie: Okay. Awesome. Let’s go ahead and take a look at customers.
Storing Customer Data
Zach: Customers. Marjorie, I’m sure you can speak to this more intelligently than me, but there’s a couple reasons that I come across people either storing customers in QuickBooks or not and this is really what we’re trying to determine, as we configure how our system is going to treat customers is, how are we going to match them? So if you have some unique naming convention on your Shopify store, for example, and that aligns with your customer name field in QuickBooks, or if you happen to have email addresses for everyone, that is an awesome matching criteria to avoid duplicates. All of these up top settings are really for if we’re bringing in customer-level information and creating customer profiles in QuickBooks. How are we going to do our best to avoid duplicates?
Marjorie: I think email is the one that we suggest using the most because in most web stores, it is a unique identifier, as they have to have a unique email address.
Zach: As much as we’re all tied to our email 24/7, probably more than we would like to be, it is beautiful then that we know that no two people have the exact same email address. With a name like Zach Smith, there’s millions of me that exist but only one of them has that incredibly long email address that I had to piece together to have both my first and last name. It’s helpful as an identifier, but we touched base on this with orders and I’m sure you can enrich what I’m about to say. We also have a number of clients, not so much in a wholesale scenario, but in a direct-to-consumer situation that will post to some “standard customer.”
It can be channel-specific, because we can configure each channel in a unique way. So if all your Amazon orders need to go to your Amazon customer, all your Shopify orders to your Shopify customer, that’s great, that’s very easy to reinforce. I have a couple of clients too, that just post everything from online sales to a customer called Online Sales Customer. There is also this idea of just simply posting to some sort of a standard customer as opposed to worrying about whether we’re going to create new ones, or what matching criteria we’re going to pass them through.
Marjorie: We like to tell our clients, if you are expecting multiple orders from the same customer, if you have a driver of a KPI that you’re tracking of how many returned customers do we have, you can see in some of the Webgility reporting as well. But if you are trying to use QuickBooks for KPI tracking on these things, then yes, create a new customer. The majority of the time, even for us here at Fourlane, we have a web store, we do not post every customer into our QuickBooks file because the customer management is happening in Salesforce for us.
That eliminates again, some of that weight that is necessary in the counting file. The counting file doesn’t care about who bought it, they care about cash, who paid it, not even who paid, they just care about that we got paid. That’s what we’re making sure that we’re tracking the cash, we’re tracking the expenses and everything that went out, and we do not need to have every single customer that’s ever bought from us maintained in multiple databases. It’s in your webstore. Maybe it’s in your CRM, maybe it’s flowing through Webgility. You don’t need to have it also go into QuickBooks. That’s usually our rule of thumb. We try to push people away from this as much as possible.
Zach: I do come across some situations with older versions of QuickBooks, they’re like, “Hey, we have 90,000 customers.” I’m like, “Oh well, you’re butting up against that limit.” Might be time to explore a standard customer or get contact with Marjorie and her team, because they can definitely point you in the right direction.
Marjorie: Consolidate. We’ve gone through with a lot of clients that show up because QuickBooks can handle a million. The most I think I’ve ever seen is a 250,000 customer list and it was slow, but we figured out ways to make that work if that’s necessary. Now, this customer, 250,000 customers, they had customers from 1995 forward, and they were residential customers, and I was like, “They probably don’t live there anymore. I don’t know if you need all this information.”
Okay, so we’re running up on time today. The sales tax, the discount, and expenses and fees I think the biggest takeaway for us: to know there is that they are recorded as lines on the transaction similar to how we would coach everybody to do that. You have a lot of options that you can do there, but I know that sales tax isn’t everybody’s favorite subject, so I think we covered the meat of what we need to get through today. You can have a multi-state, that’s always important right now as well.
Zach: We’ve always mapped multiple sales tax jurisdictions. A lot of whether or not this is important to folks is largely based on whether or not they’re using some third party that handles that for you, i.e. Avalara Tax or things of that nature but yes, we can absolutely say based off the ship-to-address record to this unique sales tax item in QuickBooks, so certainly an option. Takes a little bit of setup. Fortunately, there’s onboarding folks like Fourlane that can help you with that but yes, we can certainly record sales tax in a number of different ways, depending on how you have it set up.
Similar with discounts. Usually, it’s a matter of how we want to record them. Nothing super complicated going on here. We do want to record discounts for sure. How we do so is dependent upon the client, for sure. Then expenses and fees, monumentally important for Amazon, for example. A little less so for Shopify, Bigcommerce, WooCommerce, Shift4Shop, all of those. One thing to be noted on expenses and fees is there’s going to be some flexibility here and some of it will be driven by how you set up automation, which we can certainly touch base on in the second part of this video series here.
TRY WEBGILITY FOR FREE