Most POS integration articles begin with a list of apps. That is useful, but it skips the decision that matters: what should happen to a sale after the customer pays?
The answer is different for every team. Finance needs accurate entries. Operations needs inventory and fulfillment updates. Marketing needs customer history. A franchisor needs comparable location data. The same sale can support all four, provided the integration preserves its meaning as it moves.
This guide explains POS integration through that data journey: what the term means, which systems connect, where the data can go, how the work is actually scoped, and what goes wrong quietly when it is done carelessly. If you would rather skip to the practical part, the system directory and the product router are the two sections most readers come for.
What POS Integration Is (Point-of-Sale Integration)
POS integration connects your point-of-sale system with the other software your business uses, so sales and related data move automatically and arrive in a usable form. A single checkout can then update accounting, inventory, customer records and analytics without anyone re-entering it, and each of those systems receives the version of the sale it actually needs.
“Usable” is the important word. Moving a $1,000 total into another system is simple. Preserving what portion was revenue, tax, tips, discounts, refunds, gift cards and processor fees is the real integration work.
A POS to QuickBooks integration, for example, may turn one closed business day into several accounting lines. A POS to ERP integration may also attach a subsidiary, department and location. A data warehouse may receive every ticket and item instead of one daily summary. Same sale, three different shapes, one collection step.
What an Integrated POS and Accounting Setup Changes
An integrated POS and accounting setup means the sale is recorded once, at the counter, and every system that needs it afterwards is fed from that single record. Nobody re-keys a daily report, nobody reconciles two versions of the same day, and the books close on the same chart of accounts at every location. The practical difference is not speed. It is that one number stops having two answers.
“Integrated” is used loosely, so it helps to be concrete about what changes. Three things do.
One version of the day
Gross sales, tax, tips, discounts, refunds and processor fees arrive already separated, so the day does not need rebuilding from a spreadsheet before anyone can trust it.
One chart of accounts
Every site posts into the same categories, which is what makes location results comparable at all. Without it, a network P&L is an average of different definitions.
One place to ask why
Because the detail behind each figure survives the trip, a number that looks wrong can be traced to the tickets that produced it instead of being argued about.
The distinction that matters is between an integrated POS system and a merely connected one. A connected POS moves totals. An integrated point-of-sale system preserves what those totals were made of, routes each record to the right entity, and tells somebody when a store sends nothing at all. The maturity model further down breaks that gap into four levels, and the five silent failures are what the connected-only setups run into.
For multi-location operators this is usually the whole business case, and it is why an integrated POS and accounting software pairing gets budget when a faster export never does. Standardised accounts across every site are what make one location comparable with another, and they are the prerequisite for anything built on top of the data later. Getting there is the integration work: see how a managed custom integration is scoped.
POS Systems You Can Connect
Autymate can help you integrate any POS system, including the 23 point-of-sale platforms below and systems with no public connector at all. What differs between them is not whether integration is possible but how the data arrives, and which parts of a sale the system separates for you rather than leaving bundled together. That single answer decides most of the scope of the work.
Hover a system, then its , for what that platform bundles together and what to separate first.
ToastRestaurantsTips, comps, service charges and delivery-app payouts all need separate treatment before anything reaches the ledger.
SquareRetail & hospitalitySeveral locations often sit under one Square account, so routing each site to its own books is the first thing to get right.
CloverRetail & hospitalityMerchant-level fee structures vary by reseller, so gross sales and processing fees have to be separated deliberately.
Lightspeed RetailRetailItem-level detail is available, which usually forces the daily-summary versus transaction-level decision early.- Lightspeed RestaurantRestaurantsA different product from Lightspeed Retail, with its own tip and course structures, so the two cannot share one mapping.
NCR AlohaRestaurantsOften reached through scheduled file exports rather than a live connection, which changes how gaps are detected.
Oracle MICROSEnterprise hospitalityVolume and multiple entities are the norm, so subsidiary routing matters as much as account mapping.
Shopify POSOmnichannel retailIn-store and online sales share a catalogue and usually a payout stream, but rarely share accounting treatment, so channel revenue still needs separating deliberately.
Revel (Shift4)iPad POSMulti-establishment setups need each establishment mapped separately or store results drift together.
TouchBistroRestaurantsTips and payment types are the usual failure point: tips are a liability owed to staff, and payment types map to clearing accounts, not revenue.
SpotOnRestaurants & retailThird-party ordering flows through the same records, so commission has to be split from gross sales.
UpserveRestaurantsSold by Lightspeed to Skyview Equity in 2026, so Lightspeed-era accounts and newer ones can expose their data differently.
HeartlandRestaurants & retailIts current cloud lines expose REST APIs; the legacy estates still in the field are often database or file based, so the generation a location runs decides the path.- DinerwareLegacy restaurantA legacy estate in most cases, where the practical question is what the local database can be read from.
Epos NowRetail & hospitalitySales and refunds come across cleanly; the work is usually matching its tax treatment to your chart of accounts.
Retail ProSpecialty retailStore-and-forward setups mean data can arrive late, so date coverage matters more than timing alerts.- ErplyRetailMulti-warehouse inventory means the stock side and the accounting side often need different levels of detail.
- MPOSFranchise servicesThe proprietary point-of-sale behind The UPS Store network below, where every store carries its own QuickBooks configuration.
MindbodyFitness & wellnessMemberships and prepaid packages are deferred revenue, not sales at the moment of purchase.
WellnessLivingFitness & wellnessRecurring billing and class credits both post before they are earned, which the mapping has to respect.
ZenotiSpa & salonService revenue, retail product and gratuity split three ways, and staff commission rides on top.
BookerSpa & salonAppointment deposits and packages arrive ahead of the service date, so revenue timing needs deciding up front.
PDIConvenience & fuelFuel and in-store merchandise carry different margins and tax treatment, so they cannot share one revenue account.- Your systemNot listedWe can help you integrate it, whether it offers an API, a database, an SFTP drop or a scheduled export.
POS system integration rarely turns on whether a name is in this list. What matters is the access method, and whether anyone owns the connection once it runs. Less common and older POS platforms are a large share of this work, and they are usually the businesses where doing it by hand costs the most.
Restaurant POS Integration
Restaurant POS integration is mostly a question of liabilities. Tips, service charges, comps and sales tax are not revenue, and third-party delivery arrives net of commission that has to be split back out. Get those four right and the rest of the mapping tends to follow. Systems in this group also differ sharply in access: Toast offers a live connection, while an Aloha estate is often reached through scheduled exports.
Retail POS Integration
Retail POS integration turns on inventory and margin rather than liabilities. Because items sold reduce stock and drive cost of goods sold, the decision about daily summary versus transaction-level detail arrives earlier than it does in restaurants. Multi-location retail adds a second problem: several sites often sit under one merchant account, so each one has to be routed to its own books.
Fitness, Wellness and Salon Systems
Memberships, class packs, prepaid packages and appointment deposits all take money before the service is delivered, which makes this group a deferred-revenue problem first and a sales problem second. Booking platforms also mix service revenue, retail product, gratuity and staff commission in one record. Recognising revenue when it is earned rather than when it is collected is the whole job here.
Whichever group you are in, the destinations are the same. See every system we connect or how a managed custom integration works.
Where POS Data Can Go
The same sale can reach more than one place. POS data most often flows to accounting for the close, to an ERP for inventory and fulfilment, to a CRM to enrich customer records, to payroll for hours and tips, and to a warehouse or BI tool for analysis across locations. Each destination needs a different level of detail, which is the decision worth making before anything is built.
- POS to accounting
- Sales, tax, tips, fees and refunds into QuickBooks, Xero, Sage Intacct, NetSuite or Zoho Books.
- POS to ERP
- Transactions and inventory movement into NetSuite, Dynamics or SAP, with subsidiary and department attached.
- POS to CRM
- Purchases enriching customer profiles in Salesforce, HubSpot or Zoho so service sees the buying history.
- POS to inventory
- Items sold decrementing stock and driving true product margin rather than an estimate.
- POS to payroll
- Hours, tips and labour cost by location into ADP, Gusto or Paychex, split the way the rota was worked.
- POS to a data warehouse
- Transaction-level data into a warehouse or BI tool, which is the only route to ticket-level analysis.
POS accounting integration is the most common starting point of the six, and for most businesses it is the only one that is urgent. Rather than starting with software logos, though, it is usually faster to start with the business outcome. Most POS connections belong to one of four groups.
Financial truth
Move sales, tax, tips, fees, refunds and deposits into the correct financial records, on the same chart of accounts at every location.
Operational flow
Keep inventory, ecommerce, fulfillment, payroll and scheduling aligned with what actually happened at the counter.
Customer continuity
Connect purchases with CRM profiles, loyalty points, marketing and post-purchase service so the customer is not a stranger on their second visit.
Comparable locations
Collect every location and channel on the same definitions, so one site can be measured against another instead of against a different chart of accounts.
A business may need all four groups, and that does not mean four separate integrations. The POS can be collected once, validated once and shaped differently for every destination. That is also why adding a destination later is cheap while changing the level of detail is expensive.
POS to QuickBooks Integration
A POS to QuickBooks integration turns each closed business day into the accounting records QuickBooks expects: sales receipts or invoices for revenue, journal entries for tax, tips and processor fees, and payments matched to the bank deposit through a clearing account. Both QuickBooks Online and QuickBooks Desktop can receive it, though the delivery method differs, and each location can post to its own company file.
QuickBooks is the most common destination we are asked for, and Autymate is an Intuit Gold Partner with a listing on the QuickBooks App Store. It is not the only destination, though: the same POS data reaches Xero, NetSuite, Sage Intacct, Zoho Books and data warehouses through the same collection step, and 300+ systems are available on the same basis. Pick the destination that fits your finance stack, not the one an integration happens to support.
What actually lands in QuickBooks depends on four decisions, and they are worth making before anything is switched on.
- Record type
- Sales receipts keep the ledger compact. Invoices suit accounts with terms. Journal entries carry the tax, tip and fee split that neither of the others expresses cleanly.
- Level of detail
- One summary per location per day, or every ticket. Summaries stay readable; ticket-level detail is what makes product margin and audit possible later.
- Location structure
- Classes, locations, or a separate company file per site. The right answer depends on whether the entities are legally separate, not on which is tidier.
- Online or Desktop
- A managed workflow can shape and route records to whichever environment each store runs, so a mixed estate does not need two separate projects.
The mixed-environment case is not hypothetical. The UPS Store network below runs QuickBooks Online and QuickBooks Desktop side by side across 2,500 stores on one workflow. If you are bringing standard transactions into a single QuickBooks Online company, the self-serve Autymate Transactions app on the QuickBooks App Store is usually the shortest path. Anything with multiple entities, unusual mapping or a POS without a public connector is a custom integration instead.
POS and Ecommerce on One Catalogue
When a business sells in store and online, the two channels usually share a product catalogue but almost never share accounting treatment. Payouts often settle on different schedules, online orders carry shipping and marketplace fees the counter does not, and returns can come back through the opposite channel from the sale. Connecting POS and ecommerce means reconciling both into one revenue picture without double-counting the stock.
Ecommerce POS integration is the case most write-ups skip, and it is the one that produces the strangest month-end questions. Four differences between the two channels cause almost all of them.
Payouts do not align
Card settlement from the counter and a marketplace payout run on different cycles, so the same week’s revenue reaches the bank in two rhythms. Reconciling to deposits requires holding both against one clearing account.
Online carries fees in store does not
Shipping, fulfilment and marketplace commission are real costs of an online sale. Recording them as a reduction in revenue rather than as expense understates the channel and flatters the margin.
One catalogue, two claims on it
An item sold online and an item sold at the counter both decrement the same stock. If each channel posts independently, inventory drifts and cost of goods sold drifts with it.
Channels cross on the way back
Buy online, return in store is normal retail behaviour and awkward accounting. The credit has to land against the original channel or per-channel results quietly stop being true.
Shopify POS is the most common version of this, because there the POS and the ecommerce storefront are the same platform, which makes the catalogue easy and the accounting treatment no easier. Whatever the ecommerce system is, the workable pattern is the same: collect both channels once, tag every record with its channel before anything posts, and let the destination decide how much detail it needs. Then a per-store view and a per-channel view of the business can both come from the same data instead of competing.
Per-location and per-channel profitability both depend on the same thing: the channel tag has to exist on the record before it posts. Recovering it afterwards means re-deriving it from payout timing, which is guesswork.
The Connections People Ask For Most
Yes to all of the pairings below, and to most that are not listed. These are the ten POS integrations into accounting platforms we are asked for most often, in order. If yours is not here we can still help you integrate it, because what matters is how your POS shares its data, not whether we have built that exact pairing before.
- Toast to QuickBooks Online
- Square to QuickBooks Online
- MPOS (The UPS Store) to QuickBooks Desktop
- Clover to QuickBooks Online
- Oracle MICROS to NetSuite
- Toast to Xero
- Lightspeed Retail to QuickBooks Online
- Shopify POS to Xero
- NCR Aloha to Sage Intacct
- Revel to Sage Intacct
Two patterns are worth noticing in that list. The first is that QuickBooks dominates the destination side, which is why the QuickBooks section above goes into the record types and location structures in detail. The second is that the same POS appears against different destinations, and that is the point of collecting once: Toast to QuickBooks and Toast to Xero are the same extraction with a different shaping step, not two separate projects.
Tell us the POS, the destination and how many locations. We will tell you what it takes.
What This Looks Like at 2,500 Locations
The clearest way to explain the difference between moving data and moving usable data is a network that had to solve it at scale.
Across 2,500 of The UPS Store’s 5,500+ US locations, every store produces daily point-of-sale activity that has to reach its own QuickBooks environment. Handled by export and re-entry, that is the same work repeated thousands of times a month, and at network scale a store that sends nothing looks identical to a quiet trading day.
Autymate runs a managed workflow that prepares MPOS data for both QuickBooks Online and QuickBooks Desktop, processing journal entries, invoices, payments and credit memos according to each store’s own configuration. One mapping template is authored centrally and copied to a store the moment it connects. Per-location date-coverage checks, which exclude weekends, closures and US public holidays, raise a missing store as an exception the same day rather than letting it disappear into the month.
- 2,500
- stores consolidated into one ledger
- QBO + Desktop
- both accounting environments, one workflow
- One template
- copied per store on connection
Nearly every idea in the rest of this guide comes from work like this: templates instead of per-store setup, validation before delivery, and detecting absence rather than only errors. It is also the clearest example of the mixed-environment case from the QuickBooks section, where Online and Desktop stores run on one workflow instead of two projects.
The Journey of One POS Sale
Imagine a customer buys a $50 meal, leaves a $10 tip and pays by card. The processor later deposits $58.20 after a $1.80 fee. One checkout has created several facts that different systems interpret differently.
- At checkout
- The POS records the sale, tax, tip, payment type, items, customer and location.
- In accounting
- Revenue, tax liability, tip liability and merchant processing fees each need separate treatment. Only one of the four is income.
- In inventory
- Items sold reduce stock and may update cost of goods sold, which is what turns revenue into margin.
- In the CRM
- The purchase can enrich the customer profile, so the next visit starts with history rather than from zero.
- At the bank
- The $58.20 payout must match the sale through a clearing account, or the deposit and the revenue drift apart.
- In analysis
- Location, category and time data make one site comparable with another, which only works if every location tags those fields the same way.
The POS Integration Maturity Model
Integration is not simply “connected” or “not connected.” Most businesses move through four levels as volume and complexity grow, and knowing which one you are on is usually enough to tell you what to fix next.
- Level 1ManualReports are exported and entered by hand.
- Level 2ConnectedA standard app moves basic totals.
- Level 3ControlledMapping, validation and routing are defined.
- Level 4ManagedFailures, gaps and system changes have owners.
Level 1: Manual Handoff
Someone exports a report and types it into the accounting system. This can be entirely reasonable for a new or low-volume business. It becomes a risk when the same report is rebuilt for every store and every day, because the cost scales with locations while the accuracy does not.
Level 2: Basic Connection
A built-in or marketplace connector sends standard data. For one location with simple books this is often the right answer and nothing more is needed. The limits show up with the second entity, the first unusual mapping, or the first month nobody notices a gap.
Level 3: Controlled Integration
Transaction types, mappings, locations and validation rules are intentional rather than inherited. The workflow prevents duplicates and identifies records it cannot safely deliver, instead of delivering them anyway and leaving reconciliation to find out.
Level 4: Managed Integration
The business knows when a store sends nothing, when a destination rejects data and when an API change requires maintenance, because those things have an owner. This is what a managed integration means in practice, and it is the level the 2,500-store deployment above runs at.
Five POS Integration Failures That Stay Quiet
The most expensive failures are rarely dramatic. Totals still appear, dashboards stay green and the problem is discovered later during reconciliation or location review.
Net deposits are recorded as revenue
Processor fees disappear and revenue is understated. Separate gross sales from fees and reconcile through the settlement, not the deposit.
Tips and tax inflate income
Money owed to employees or tax authorities is treated as revenue. Confirm the accounting treatment with whoever owns the chart of accounts before launch, not after.
A correct sale reaches the wrong location
Network revenue remains correct, so the mistake hides inside an inaccurate store P&L. Nothing looks broken at the top; only the site comparison is wrong.
A retry creates a duplicate day
The same business date posts twice because the connection lacks a stable source reference. Duplicate prevention has to be designed before launch; it cannot be added afterwards without cleaning history.
A store sends nothing, and nothing alerts
Absence is not a technical error, so nothing fails. Detect it by comparing expected trading dates against received records, which means the system needs to know the trading calendar.
A green sync status is not the same as correct books
Autymate validates mappings, destinations, duplicates and expected data coverage, not only whether an API call succeeded. All five failures above return a successful API response.
Mapping, validation, routing and monitoring, managed end to end.
The Multi-Location POS Integration Playbook
At one location, the primary question is whether the total is correct. Across several locations, you must also prove that every record reached the correct store, company or subsidiary. That second proof is what most integrations are missing.
Define the network standard
Agree on common sales categories, transaction types and accounting treatment before anyone connects.
Create an organization template
Build shared mapping once instead of configuring every store from zero.
Separate what varies
Keep credentials, company files, classes and location IDs configurable per store.
Test the first business day
Verify results inside the destination, not only on the integration dashboard.
Watch for absence
Use trading calendars to identify a location that did not report at all.
Design the next store now
Opening location eleven should be onboarding, not another integration project.
This is the sequence behind The UPS Store customer story, and it is the same sequence whether the network is eleven sites or two thousand. What changes between operating models is who owns the chart of accounts, not the order of the steps.
Choose the Smallest Solution That Controls the Risk
Custom is not automatically better. The right solution is the least complex option that handles the data, controls and ownership your business actually needs.
| Your situation | Best starting point | What to verify |
|---|---|---|
| One location, daily totals, standard books | Built-in POS connector | Tax, tips, fees and refunds map correctly |
| A few locations with the same structure | Configurable marketplace app | Location routing and per-store pricing |
| Low volume or temporary process | Manual export | Ownership, review and duplicate controls |
| Several locations, entities or destinations | Custom integration | Reusable templates and monitoring |
| Financially sensitive or high-volume workflow | Managed integration | Exception handling and ongoing ownership |
Plan the Setup, Then Test the First Day
Most of the work happens before anything is switched on. Three decisions and one review, in that order.
The Mapping Decision
Where each type of sale belongs in your accounts. This is one or two sessions with whoever owns your books, and it determines everything after it. Teams that rush this spend the following quarter arguing about which number is right.
Access to Both Systems
Read access to the POS, and the ability to post into your accounting or ERP system. How your POS hands data over decides most of the scope, which is why it is the first question we ask rather than the last.
How Much Detail You Want
A daily summary per location, or transaction-level records. Both are legitimate. This one is expensive to change later because it decides what has already been written to your books.
Reviewing the First Week
Somebody checks the first few days inside the destination system and confirms they are right. After that it runs unattended, which is the entire point.
Before the First Unattended Sync
Take one real business day and answer these eight questions. If any answer is “we are not sure”, that is the thing to fix before launch rather than after.
- Do gross sales in the destination match the POS?
- Are tax, tips, discounts, refunds and processor fees separated correctly?
- Does the bank payout reconcile with the payment data?
- Did every record reach the correct location or entity?
- Can the same day be retried without creating duplicates?
- What happens if a required account becomes inactive?
- Who is alerted if the POS sends no data?
- Who owns the integration when either system changes?
Which Autymate Product You Need
Two answers, depending on what you are moving and how complicated it is.
- Standard import
Autymate Transactions
Bringing transactions into QuickBooks Online for a single company, in a standard shape. Self-serve, on the QuickBooks App Store.
See Transactions → - Anything custom
Custom Integrations
A non-QuickBooks destination, several locations or entities, unusual mapping, or a POS with no public connector. Built and managed for you.
See Custom Integrations →
If neither is obviously yours, that is usually a sign the answer depends on how your locations are structured rather than on which product. That is a five-minute conversation, not a scoping exercise.
POS Integration FAQs
POS integration connects a point-of-sale system with another business platform so sales, payments, inventory, customers and related data can move automatically and arrive in a usable form, rather than being re-entered by hand.
Common destinations include QuickBooks Online and Desktop, Xero, NetSuite, Sage Intacct, Zoho Books, Salesforce, inventory systems, ecommerce platforms, payroll applications, databases and BI tools. Autymate connects 300+ systems on the same basis.
Toast, Square, Clover, Lightspeed, Shopify POS, Oracle MICROS, NCR Aloha, Revel, TouchBistro, SpotOn, Heartland, proprietary systems like The UPS Store's MPOS, and others all connect to QuickBooks Online or QuickBooks Desktop. A POS with no public connector can still be connected if it exposes an API, a database, an SFTP drop or a scheduled export.
Yes. The work is in the treatment rather than the connection: Toast records tips, comps, service charges and third-party delivery payouts alongside revenue, and each needs separating before it reaches the ledger. Tips and tax are liabilities, not income, and delivery commission has to be split back out of gross sales.
A daily summary keeps the ledger readable and is enough for many businesses. Transaction-level data is useful for product margin, ticket-level audit and analytics. Different destinations can receive different detail, so this is not an all-or-nothing choice.
Yes, and they should, provided each record is tagged with its channel before anything posts. In-store and online sales usually share a product catalogue but not their payout timing or fee structure, so combining them without a channel tag makes per-channel margin impossible to recover later.
Check completeness, mapping accuracy, duplicate prevention, location routing, reconciliation, exception handling and whether missing data produces an alert. A green sync status only confirms an API call succeeded, not that the books are correct.
Not always. Use a standard connector if it already supports your mappings and controls. Custom integration is most useful for unique workflows, multiple destinations, several legal entities, reusable per-location templates, or a POS with no public connector.
Yes, though the delivery methods differ. A managed workflow can shape and route records to the correct accounting environment for each location, which is how a network running both environments side by side stays on one workflow instead of two projects.
It is quoted per business. Price is driven by how many places the data has to reach, how much detail you want, how many locations and legal entities are involved, how consistent your accounts already are, and whether historical data needs bringing in.
One location into a modern cloud accounting system is quickest. It takes longer if your POS only exports files, if each location has grown its own way of naming accounts, if you want past history brought in, or if you have several separate companies to keep apart.
Mostly one or two sessions with whoever owns your accounts, then access to both systems, then a review of the first week. After that, close to nothing, which is the point.
It rarely matters. We can help you integrate POS platforms that are not on the list, including less common and older systems, which are a large share of this work. What we look at first is how your system shares its data: an API, a database, an SFTP drop or a scheduled file export.
Bryan founded Autymate after more than a decade building financial automation systems, and leads client engagement on the integrations the team ships. His focus is turning manual, multi-system workflows into low-code data integrations and custom applications for multi-location and financially sensitive businesses.
Autymate designs, builds and manages data flows between POS, accounting, ERP, CRM, databases and 300+ systems, with a focus on multi-location and financially sensitive workflows.
Bryan on LinkedIn →
autymate