Accounting

QuickBooks is right. Your webshop and CRM are still typing the same numbers twice

QuickBooks Online is where US businesses keep the official version of revenue, expenses and tax. WooCommerce is where the order happened. HubSpot is where the deal was won. Stripe is where the money cleared.

When those four do not talk, somebody rebuilds each sale in QuickBooks by hand — customer, line items, sales tax, payment method — and the books drift from reality by the end of the month. That is not a QuickBooks limitation. It is the gap between the system of record and everything that feeds it.

  • QuickBooks Online API and webhooks
  • Sales tax, products and payment status matched
  • From $1,900 plus service fees
The tool

What QuickBooks Online is, and what a connection into it actually has to carry

QuickBooks Online is Intuit's cloud accounting platform for small and mid-size US businesses: customers, invoices, bills, expenses, bank feeds, payroll add-ons and tax reporting, with a REST API that most integrations use to create or update records. It is the default choice in the US for the same reasons Mollie is in the Netherlands — familiar to bookkeepers, accountants and banks, with a large app marketplace on top.

What makes a QuickBooks connection worth doing properly is not the API call to create an invoice. It is everything around that invoice: the customer matched on a stable ID, products and SKUs mapped to the right income accounts, sales tax calculated for the right state and county, and payment status that flips to paid when Stripe or another provider says it did — not when somebody remembers to click "Receive payment" on Friday afternoon.

US sales tax adds a layer European shops rarely face: rates vary by state, city and product category, and a webshop that charges the wrong rate creates either a compliance problem or a margin surprise. A connection that pushes the order total without the tax breakdown QuickBooks expects is the one that leaves your accountant fixing differences every month.

What goes wrong

Three things that go wrong between QuickBooks and a connected shop or CRM

QuickBooks itself is rarely the problem. These are what happens when each system keeps its own copy of the same sale.

Orders get re-entered as invoices, and line items never quite match

A WooCommerce order arrives with a discount on one line, shipping on another and tax split across two jurisdictions. Somebody opens QuickBooks and rebuilds it from the order email. The total is close enough for the customer, but not for the P&L — one product lands on the wrong income account, shipping tax disappears, and month-end reconciliation finds a few hundred dollars nobody can explain without opening both systems side by side.

What you see instead

The order is the last time anyone types it. It becomes a QuickBooks invoice with line items, tax codes and accounts mapped once and checked, so what the customer paid and what the books show are the same number.

Stripe says paid, QuickBooks still shows open, and collections emails go out anyway

The customer paid through Stripe on Tuesday. The invoice in QuickBooks is still open because nobody marked it received, and the automated reminder fires on day ten. It is embarrassing for a customer who paid a week ago, and it is the kind of small failure that makes people stop trusting either system.

What you see instead

Stripe's webhook marks the matching QuickBooks invoice paid within seconds, with fees booked separately so the payout reconciles cleanly when it hits the bank.

HubSpot closes a deal, and QuickBooks never hears about it until invoicing season

Sales works in HubSpot. Finance works in QuickBooks. A deal marked won in HubSpot does not become a customer or an invoice in QuickBooks until someone exports a spreadsheet or copies fields by hand. New customers exist in one system weeks before the other, and repeat buyers get duplicate records because email matching was never reliable.

What you see instead

A won deal creates or updates the QuickBooks customer with a shared reference, and optional invoice creation uses the products and amounts already agreed in the CRM — one customer record, one source of truth for the email address.

The bill for doing it by hand

What manual work between QuickBooks and your shop actually costs

The visible cost is re-entry: thirty to eighty orders a week, each taking three to eight minutes to turn into a correct QuickBooks invoice, is two to ten hours a week of work that both systems could do. At a loaded cost of $45 an hour, that is $350 to $1,800 a month on arithmetic.

The invisible cost is trust. An aging report nobody believes, sales tax filings built on numbers that were "close enough", and a CRM that says a customer bought last month while QuickBooks still shows them as a prospect — those do not line-item easily, but they slow decisions and create the kind of month-end scramble that keeps good people doing work computers should own.

  • Two to ten hours a week turning shop orders into QuickBooks invoices by hand.
  • Payment reminders sent to customers who already paid through Stripe.
  • Sales tax differences found at filing time instead of at checkout.
  • Duplicate customers because HubSpot and QuickBooks never shared an ID.
What we build

We build the thing on the other end too

With QuickBooks the mapping work comes first: products to income accounts, tax codes to jurisdictions, and one decision about which system owns the customer record. Get that right and the API work is straightforward.

A connection needs two ends. Plenty of agencies will build you the API call and hand you a JSON payload; that is the easy half. The harder half is what the data lands in — a website, a webshop, a portal your customers log into, an internal tool that replaces a spreadsheet. JKC builds both ends, which is why the connections we build tend to keep working: nothing about the receiving side is a black box to us.

API integrations

The connection itself: authentication, field mapping, rate limits, retries and a queue that survives the other system being down for an hour. Built against the documented API where there is one, and against whatever the vendor really offers where there is not.

Websites

WordPress sites that read from your systems instead of repeating them by hand: a careers page fed by your HR system, a team page that follows your payroll, prices and availability that are the real ones.

Webshops

WooCommerce shops where the order is the last time anyone types it: it becomes an invoice in your accounting package, a label at your carrier, a stock mutation in your warehouse, and a line in your CRM, on its own.

Web applications

When the process does not fit any standard product: a customer portal, a quoting tool, a planning board, a dashboard that reads three systems at once. Built on your data, with your systems as the source instead of a copy of them.

What can be connected

What can be connected between QuickBooks, your shop, CRM and payments

QuickBooks sits at the centre of the US finance stack for most clients on this page. These rows are the ones we most often wire first.

  • Customers from your shop or CRM

    Created or matched in QuickBooks on a stable external ID, so a returning buyer updates one record instead of spawning a second one with a slightly different company name.

  • Invoices and sales receipts from paid orders

    Line items, discounts, shipping and sales tax broken out the way QuickBooks expects, mapped to the right products and accounts — not a lump sum with a memo.

  • Payment status from Stripe or another provider

    Paid, refunded and partially refunded, each with the fee booked separately so bank deposits reconcile without manual splitting.

  • Products and inventory items

    SKU, description and income account mapped once, so every future order uses the same QuickBooks item instead of inventing a new one per sale.

  • Invoice and balance data back to HubSpot or your portal

    So sales sees what is outstanding without logging into QuickBooks, and customer-facing portals show the official balance rather than a guess from the shop.

Rows one, two and three together are what most US shops need on day one. Product mapping and CRM read-back are worth adding when volume or sales complexity makes them matter.

How it works

How a connection gets built at JKC

The same four steps every time, whichever tool it is. Nothing here is a workshop you pay for: step one exists because scoping a connection wrong is the single most expensive thing that can happen to it.

  1. 1. We look at what is actually being retyped

    Not "which fields exist" but "which fields does somebody currently move by hand, how often, and what breaks when they get it wrong". Most projects turn out to need two or three flows, not a full two-way sync of everything. That conversation is what keeps the quote where it is.

  2. 2. We pick the route, and say why

    A maintained connector from the vendor, a platform like Make or Zapier, or a custom integration against the API. Cheapest first, not custom first: if a supported plugin does exactly what you need, that is the answer and we will tell you so. Custom is for the cases where the off-the-shelf option would need so much configuring that it becomes the fragile option.

  3. 3. We build it to survive the other system

    Every connection ships with retries, a queue and an idempotency key, so an order that arrives while the other side is down is delivered later rather than lost, and a retry does not create a second invoice. On a test environment first where the vendor offers one, so the first thing your real administration sees is a working connection.

  4. 4. We hand it over with the failure modes written down

    Which alerts you will get, what each one means, what to do about it, and who to call. Plus the credentials in your own name, in your own vault — not in ours. A connection nobody but us can maintain is a connection you do not own.

More about system integrations at JKC

After it goes live

A connection that fails silently is worse than no connection

This is the part most quotes leave out. A connection that stops working without telling anyone is worse than manual work, because with manual work at least somebody notices when it does not get done. Every connection JKC builds is monitored, and the monitoring is not an upsell — it is in the service fee.

An alert per failed message, not a monthly report

A message that does not get through raises an alert the same hour, with the record it was about. Not a dashboard you have to remember to look at.

Replay, not re-enter

Anything that failed sits in a queue and can be sent again once the cause is fixed, in order. Nobody goes back through yesterday to find the four orders that did not land.

We watch the vendor's changes, so you do not have to

APIs get versioned, deprecated and rate-limited. When a vendor announces a change that affects your connection, adjusting to it is part of the service fee, not a new project.

What it costs

From €1,700, and the biggest variable is who built the other end

QuickBooks has native apps and Zapier recipes for simple one-way syncs. Custom work earns its place when sales tax, Stripe fees, refunds and CRM ownership need to be correct together — not "close enough" on a spreadsheet.

A connection starts from €1,700 plus a monthly service fee, which covers the monitoring, the queue and keeping up with the vendor's API changes. Work outside a fixed scope is €95 per hour.

What moves the number is not the tool — it is how well the system on the other end is known. If JKC built your website, your webshop or your web application, we already know its data model, its edge cases and where its stock numbers really come from, and a connection into it is mostly configuration and testing. If it is a system we have never opened, we start with a short technical check of both sides and quote after that, so you are not paying hourly for us to work out the basics.

Two more things that move it, in our experience more than anything else: whether the tool has a real API or only a CSV export, and whether the sync has to go both ways. One-way is roughly half the work of two-way, because two-way means deciding, per field, which system wins when they disagree — and that decision is the expensive part, not the code.

Questions

Questions we hear about QuickBooks connections

We build for QuickBooks Online. Desktop has different integration paths — often via a third-party connector — and a different support lifecycle. If you are still on Desktop, that migration question is worth settling before any connection is scoped.

Most new US clients we work with are already on QBO, or planning to move there because their accountant requires it. We can connect either side of that move, but not both at once as if they were the same API.

Often next to this one

Tools that often sit next to this one

Almost nobody connects one tool. These are the ones that come up in the same conversation, either because they sit in the same part of the business or because people ask for the two together.

See all integrations

Free, 10 minutes

Not sure where the manual hours actually go?

That is what the Growth Scan is for. Ten minutes, no sales call attached: you get back where the double work sits, which connection would pay for itself first, and which one honestly would not.

Do the free Growth Scan