Must I Integrate Point of Sale with Financials?

Integrate Point of Sale (POS) with Financials? Of course not. Absolutely. Maybe. A lot of integrations have been successful, some have failed, and many are probably somewhere in between.

Here are comments from some of our clients:

• “There is an option in my POS system that says something about QuickBooks. I just clicked the box and filled in the requested fields. The help said it was just that easy.”
• “It made me nervous so I didn’t want to turn it on and, instead, we’ve been manually entering daily sales.”
• “My POS system syncs to QuickBooks and it says the data is transmitted. My bookkeeper never mentioned there are any issues.”
• “I didn’t know it could send data to QuickBooks.”
• “They said it integrated with QuickBooks but didn’t tell me it only integrated with QuickBooks Online and I use QuickBooks Desktop.”
• “The documentation said it integrates with QuickBooks so I assumed it sent all the needed data to QuickBooks, only to discover that it only sends sales data, and even that was not accurate.”
• “Our consultant set it up and it is working well but it does take some effort on our part to make sure it is done right. Our bookkeeper still has to do some magic each month.”
• “I used to have the system send data over to QuickBooks but it was always such a mess so I stopped.”

If you talk with an accounting professional, integration is key. However, the business owner doesn’t necessary list this on the same level of significant priorities for a variety of realistic scenarios.

To me it comes down to two simple factors – the capability of the POS system to send the necessary data to the financials; and for those managing the retail operations to follow the required procedures. If one of these falls short, the quality of the financial information is in question and the last thing you want is a financial mess. Unfortunately, this is not an uncommon situation.

So what does one do? And how does one decide? Good questions. The intention of this article is to provide some insight into assorted approaches so you can make an educated decision in your circumstance. We’ll start with some background, review integration approaches, provide some samples, and end up with an IMHO.

Background

Many Point of Sale (POS) systems tout the ability to send financial data from POS to an accounting application. QuickBooks is the most common accounting application in the small business market but many work with Xero and a myriad assortment of other accounting applications.

The integration can take on different forms – automated direct integration on a periodic basis, push of a button, distribution of a transaction file from the POS to be imported into the financials, etc. And in certain cases it is manual entry based on certain POS reports.

The breadth and depth of the sales data can vary as well – high level summary sales data, summary of sales at a particular level, inventory related activity, detailed sales for certain types of sales, all sales activity. Some are sent as sales and payment documents and some as journals and some as a combination of both.

The devil is in the details when it comes to determining viability of integration. Per usual, reviewing this with someone who has experience in this regard is important.

Does it Integrate?

You will want to check with your POS vendor or reseller/consultant to determine whether there is integration with your specific accounting application. However, just saying it integrates doesn’t mean it will meet your needs. In fact, some have caused more harm than help.

In the QuickBooks world, there are the QuickBooks Desktop applications and QuickBooks Online. If it integrates with QuickBooks Desktop then it will likely work on all PC desktop versions – Pro, Premier, Enterprise. Most do not work with QuickBooks for Mac and if they do it is via an IIF format file, which isn’t necessarily a deal killer but it certainly is not the preference. Most of the online POS systems will integrate with QuickBooks Online but some of the desktop POS systems will not.

Just because there is integration, doesn’t mean it is viable. For example, the first Square integration with QuickBooks was … awful. The second round was written by Intuit and works a lot better. Basically, only sales information is transferred and a number of users are still reporting issues but the foundation is there. Same with the Revel to QuickBooks integration prior to the partnership with Intuit, where it actually caused issues in the financials, but after a lot of input from the QuickBooks POS community, it is much better.

Some POS systems have built their own integration (QuickBooks POS Desktop, Revel, Vend, Square’s integration is available from Intuit, etc.) and some utilize a 3^rd party for integration. For example, the applications vendor Shogo performs the integration between 11 different POS systems and QuickBooks Desktop, QuickBooks Online, or Xero. Some of these are white labelled so when you want to integrate with QuickBooks or Xero, the POS vendor touts it as their own but uses Shogo behind the scenes. Nothing wrong with this approach, however it usually means an additional fee for the integration.

Here’s a very brief review of POS systems that integrate with an accounting package. It is possible that 3^rd party tools provide additional integration, especially with QuickBooks Desktop. This list is not intended to be comprehensive but to provide an inkling as to the breadth of integrations. Just because they are on this list doesn’t indicate an endorsement of the integration.

If the POS system does not provide any integration, there are likely other methods to record the necessary information in the accounting system. See section below regarding manual integration.

What Kind of Information Can Be Sent to Accounting?

There are different levels of integration – sales summary, sales by category, sales by item, detailed sales, Accounts Receivable, etc. It is difficult to know what should be sent to the accounting system, so let’s start with the different types of activities that could be sent.

When I first started writing these down I knew it would be a long list — but not this long! Amazingly, not all the pieces have even been puzzled together. This might not be the most riveting topic, but it highlights how beneficial a well-tuned automation can be to a business.

• Customers. The more sophisticated ones have the option to sync customers and customer balances. This raises the question of whether you want to track customers in both systems or just have them sit in the POS. And then there is Accounts Receivable. If you want to track A/R in the accounting application you need customer information. Most do not pass this level of information from POS to accounting.
• Items/Products. Some form of item is required if sales receipts or invoices are used. The summary ones will consolidate items into a group – non-taxable or taxable by department/category, etc. — whereas the more detailed ones sync all items.
• Revenue. This is the actual price of what was sold. Some nuances:
  • Some integrations send the net after discounts; some are able to split out discounts to a separate discount account.
  • Some post all sales into a single or very limited set of revenue accounts, which may or may not include shipping, discounts, gift certificates, etc. Some include sales tax in the revenue posting.
• Taxable sales versus non-taxable sales. Some break these out separately and some group them together.
• Discounts. More sophisticated ones are able to break out line item discounts so it can be booked to one or more accounts, e.g., contra-income account.
• Gift certificate/Gift card. Some post to an assigned liability account, some lump into revenue, some don’t send at all.
• Sales Tax. This can be tricky. Some lump sales tax into the revenue figures, some create sales tax as a line item on the sales receipt or invoice, others assign a sales tax code at the bottom of the sales receipt/invoice. Sales tax for orders shipped out of town is another challenge in and of itself.
• Payments. This includes cash, check, credit cards, gift cards/certificates, promos, etc. These could be passed along as line items on the sales receipt/invoice or as a payment against the invoice.
• Credit card payments. Sending the daily credit card payments is a very typical transaction. However, it is important that POS deposits match the actual credit card bank deposit. There are subtleties based on the merchant service cutoff time. For example, the merchant service in a POS might cut off charges before the close of business for the day — thus the amount to be deposited will never match the actual bank deposit. Some merchant services take out the fees in their deposit rather than depositing the gross amount of credit card sales in one transaction and the fees in a separate one.
• Accounts Receivable. Also known as House or Charge Accounts. These occur when a payment is not made at the time of purchase and payment is expected at a later date. Ideally, payments against an invoice(s) can be taken in either system and each system would be aware of all activity regardless of where it was initiated. Statements can be sent from either system, and customer’s outstanding balances are real-time in both systems, etc. Yes, this is a tough one, which is why A/R is usually handled in one place — and most of the time that is in the POS because it is hard. A number of POS applications do not have any A/R type of capability, let alone usable integrations.
• Multiple locations. Multiple stores/locations – brick and mortar and/or online – might be tracked as such in the accounting package, e.g., different locations or classes. With franchises, certain locations could be different entities with a different set of books (company files). Some want to track sales of the same product across location in a different set of GL accounts. Many have minimal or no multi-location capability.
• Product purchases. The receipt of inventory is handled in the POS. Not all systems will transfer these purchases to the accounting system. The vendor’s invoice is usually not paid in the POS system but rather in the accounting application. Thus, certain systems send over a bill or purchase order to increase the inventory value and A/P; the more simplistic ones do not do anything relating to vendors, Accounts Payable, bills, or inventory in general. And with others it is an option.
• Product returns. If product purchases are sent to the accounting system, hopefully returns are too, though that is not always the case.
• Vendors. Some will sync vendors both ways and some will just send from the POS system to QuickBooks.
• Purchase Orders. Some will send purchase orders to the accounting system for processing. Most do nothing with POs, given that it is not a true financial transaction.
• Inventory sales and Cost of Goods Sold (COGS). When an item is sold, the cost of that item is deducted from inventory and booked as COGS. This is one of the areas that can be most troublesome to the financials as it is critical for the POS to maintain the appropriate cost of each item so that the inventory and COGS can be updated and maintained properly. Most systems have issues when a product is sold before it has been received.
• Inventory adjustments. This activity includes any changes to the inventory that is recorded in POS – cost, shrink, damaged inventory, donations, in-store use, physical inventory, etc. The change in inventory value needs to be adjusted.

That was exhausting! As you can see, there is a lot of information that can be sent to the accounting system. And I’m sure I missed some. Therefore, reviewing requirements of the business is very important.

And you will need to find out more about how and what the POS transfers to accounting and if it is a two-way or one-way sync. [More….]