E-Commerce Platform and Accounting Integration

Jonathan Pincas
Mar 18 · 6 min read
Ecom and accounting integration is a real headache

Accounting and financial control, and how these processes link to your e-commerce system, is a truly thorny issue — perhaps the most challenging to solve for business owners selling online. There is software designed to do your accounting and financials and there is software designed to sell online, but they are rarely the same system. Systems that have fully fledged accounting and fully fledged e-commerce baked into a single platform have always been firmly in the enterprise space and out of reach for most small businesses. In addition to accounting, there are myriad other software systems engineered to help you with more specific tasks, like demand planning or customer issue management, that also have to be considered when thinking about integrations.

All of these systems require access to your business data in one way or another and there is significant overlap between the data requirements of each system. This leads to one, essential question that you have to answer: which data sources are my “sources of truth” and which are “replicated”.

That’s such an important decision that it requires some illustration. Let’s examine a simple setup consisting of an e-commerce platform, like WooCommerce, an accounts package, like Xero and eventually, an Inventory Management system. Let’s focus only items, customers, supplier, sales orders and purchase orders and try to weave a “story” that might be representative of a typical online sellers thought/action process as they build their business.

  • I’ll be selling my products mostly online, so I’ll create my items in WooCommerce
  • Customers will sign up online, creating customer records in WooCommerce
  • Customers will place orders online, creating orders in WooCommerce
  • Xero needs to know about orders to do accounts, so I’ll get an integration to replicate order data from WooCommerce to Xero
  • But orders contain both item and customer data, so I’ll need an integration to replicate item and customer data from WooCommerce to Xero
  • OK, so I guess Xero will be my source of truth for order data
  • In that case I’ll have my admin staff enter telephone and email orders into Xero directly
  • In which case item information will need to be up-to-date in Xero, so we’d better treat Xero as the source of truth for item information
  • In which are we should sync back item data from Xero to WooCommerce
  • Oh, we should probably do the same for customer data too
  • Oh, but customers can edit their account in WooCommerce, so we’ll need a bi-directional sync for that
  • Hmm, does that make Xero or WooCommerce my source of truth for customer data?
  • Anyway, customers pay by card online, so I’ll need to sync payment data from WooCommerce to Xero
  • But we can also take payments over the phone, or receive bank transfers, so we’ll need to be able to enter payments manually into Xero
  • And if we don’t sync those back to WooCommerce, customers’ orders in their ‘My Account’ area will be out-of-date.
  • Hmm, maybe we just need a bi-directional sync for everything??
  • So where do I tell my staff to make changes?
  • Right, I’ll tell them make changes to everything in Xero and we’ll call that our source of truth
  • Ah but wait, there are some product description fields in WooCommerce that don’t correspond to anything in Xero, so THOSE changes will need to be made in WooCommerce
  • Plus, of course, the blog content and data like that, which is only in WooCommerce
  • Great, so I’ve made a manual for my staff explaining where every change needs to be made. Now to just set up and turn on this bi-direction sync.
  • Damn, this thing is buggy, so many edge cases. Never mind, let’s move onto stock management
  • Remind me again, which is my source of truth for stock levels, WooCommerce or Xero?
  • I guess it doesn’t matter, since we have a bi-directional transaction sync, the stock levels will always match up perfectly right?
  • Damn, they don’t seem to, where do I start searching for the discrepancy?
  • I know, I’ll contract inventory management software to streamline my purchasing and stocking
  • I’ll need to sync item data from Xero to the Inventory Management System
  • Ah, but Xero should be the source of truth for purchase orders right, so I’ll actually need to sync purchase order data from the Inventory Management System to Xero
  • Another bidirectional sync, this is ringing a bell…
  • Never mind, there’s a company that can do that for me, so let me get those two system running a two-way sync
  • Great! My new Inventory Management software is running management of stock levels and those are being synced back to Xero which in turn are being synced down to WooCommerce.
  • Where does supplier data go? Definitely not in WooCommerce. I think it should be centralised in the Inventory Management system and synced to Xero

I won’t go any further — partly because it’s already getting incredibly grating, and secondly, I think you already know where this is going. There are a couple of lessons we can extract from the above:

  • Choosing a “source of truth” for data is not trivial
  • Bi-drectional syncing between data systems is hard, if not impossible, to get right and requires constant maintenance
  • Data duplication is a constant problem
  • The technical overhead of setting up and maintaining these webs of integration is very high
  • Training staff to use such a complex web of systems is tough and monitoring to make sure they continue to use them in the right way is even tougher
  • The opportunities for incorrect data to surface are high
  • The potential for bugs, problems, malfunctions, crashes and technical dropouts are magnified
  • Day-to-day use of such systems is clunky and frustrating
  • They quickly lead to high levels of “technical debt”

Technical Debt

In software development there is a great term: “technical debt”. Technical debt is what you accumulate as you add “components” to a software project — normally these are libraries, packages and other dependencies that originate from outside your organisation, meaning you depend on others for their long-term maintenance and health. It’s called “technical debt” because at some point it comes back to bite you and you have to “pay it back”, normally with “interest”. Sometimes technical debt gets so bad that projects are just abandoned or restarted, which is called “technical bankruptcy”. This is way more serious problem than you might think.

Here’s the thing though, technical debt isn’t just limited to software projects. All businesses accrue technical debt according to the software choices they make along the way. The world moves forward, lately at a scary pace, and the software you use sometimes (most of the time?) doesn’t necessarily keep up. That’s why so many companies are using obsolete systems that don’t serve theirs’ or their customers’ purposes any more. Just look at how badly broken most small business e-commerce sites are: it’s because they are using hugely outdated versions of software that they dare not touch for fear of breaking the interconnected web of software systems they’ve patched together over years of gradual debt accrual. Payback time usually means rebuilding everything from scratch every 5–10 years.

Just talk to any e-commerce business owners that are currently trying to decide whether to upgrade their Magento installation to version 2 or hobble along for another year in their current state — they’ll know exactly what I mean.

The Pakk Approach

As the founders of Pakk, we’ve been burned by technical debt in our own e-commerce businesses over the last 15 years. Pakk, a “one-platform” approach, seeks to kick technical debt out of the equation by integrating everything that is necessary for the running of a modern all-commerce business into one place, and that includes accounting. If you’ve never used a full-service ERP which integrates proper, ledger-based, double-entry booking and accounting along with everything else, it’s truly a beautiful thing to behold. Consider all these examples:

  • Make a sale — accounts that track revenue go up
  • Ship stock — accounts that track inventory value go down
  • Receive a payment — accounts that track physical financial institution accounts move in tandem, ready for reconciliation
  • Give credit — accounts receivable is up to date
  • Place a purchase order — accounts payable is up to date
  • Receive a purchase order — inventory value accounts go back up
  • Calculate VAT owed — easy, since all VAT-impacting transactions are in one place
  • Pay VAT each quarter — vat on sales, vat on purchases and vat liability accounts all move to reflect reality
  • Expenses — lodge them right in Pakk, observe expense tracking accounts update
  • Manual adjustments — make journal entries right alongside the rest of your data

Just think about it — when a single system knows about every sale, every purchase and every movement of stock it can track value in real time in a manner which just isn’t possible with any other setup.

That’s why we built accounting right into Pakk, alongside everything else you need to run your business. No technical debt and no complex integrations means you just get on with running an effective commerce business.

Pakk Labs

This is where we share the insight from planning, architecting and building our integrated commerce platform for ambitious small businesses. You’ll find all sorts of original research, roundups, tutorials, explainers and guides related to small-business online selling.

Jonathan Pincas

Written by

Full stack web developer and founder of pakk.io where we’re currently building a next-generation, integrated commerce platform for ambitious small businesses.

Pakk Labs

This is where we share the insight from planning, architecting and building our integrated commerce platform for ambitious small businesses. You’ll find all sorts of original research, roundups, tutorials, explainers and guides related to small-business online selling.