You can buy Stripe and QuickBooks. You still have to build the workflow.

You can subscribe to a payments product on Monday and an accounting product on Tuesday and still spend Wednesday asking why a refund exists in one place and not the other. That gap is not a missing dashboard. It is a missing **workflow**. Vendors sold you systems that are good at their jobs. They did not sell you when an invoice is real, when a SKU is the same object in two catalogs, or who is allowed to click refund.

This is operations software. **This is not financial, tax, or investment advice.** It is not a pitch to grow revenue, cut taxes, or “automate profit.” Chart of accounts, filings, and treasury policy belong to people licensed for that work. What follows is the middle: events, records, permissions, and the glue a software team actually builds.

Three products, not two

People talk as if “Stripe plus QuickBooks” is a stack. It is three layers, and only two of them come with a login.

**The payments product** is where money movement is attempted, captured, failed, disputed, or returned. It holds payment methods, processor customers, and a firehose of events. It is good at taking a card and telling you, in its own language, what happened. It is not your general ledger, packing list, or rate card. It does not know that “Studio Day Rate — overnight” is a different SKU from “Studio Day Rate — weekend” unless you taught it that.

**The books product** is the durable, dated story of what was billed, owed, paid, and reversed — in *accounting* language. Invoices, payments applied, credit memos, books customers, periods, posted numbers. It does not watch checkout in real time unless something carries the news.

**The glue** is everything that translates one language into the other without lying. Webhooks. Idempotent writes. Invoice creation and voiding. Refunds that land in both systems in the same direction. SKU and item mapping. A record of who did what. A place your staff live that is neither the Stripe dashboard nor the QuickBooks home screen, because those two UIs were not designed as your operating manual.

If you skip the glue, a human becomes the glue. That human is usually a founder, an office manager, or a contractor with a spreadsheet and a password manager. The business then has a third system anyway. It is just undocumented.

What the payments product is for (and what it is not)

Use the payments product for collecting, retrying, and recording *processor* truth. A successful charge is a fact in that world. A failed charge is also a fact. A dispute is a fact with a clock. Those facts should be stored as they arrived, with the vendor’s identifiers intact.

Do not treat the payments dashboard as:

Your catalog of what you sell Your source of “the invoice” Your staff permissions model for refunds Your customer relationship record beyond “how they paid” Your inventory, scheduling, or fulfillment state

This shows up the first time someone refunds in Stripe, forgets QuickBooks, and a client gets a reminder for a balance that no longer exists — or voids an invoice while the card capture still looks like a completed sale.

Several people with the dashboard login is a vendor default, not a studio policy. Policy is software you write or configure on purpose.

What the books product is for (and what it is not)

Use the books product for the story you need when someone asks what happened in a period. Invoices that represent work you billed. Payments applied to those invoices. Credits that reverse or reduce them. Customers as the accounting system understands customers.

Do not treat the books product as:

A real-time listener for every card event A product catalog with variants, add-ons, and internal codes that match checkout A workflow engine for “draft → sent → paid → refunded → closed” A place to store API keys, webhook secrets, or card data

QuickBooks (and tools in the same category) can connect to banks and some processors. A bank feed still is not a workflow. It says money arrived. It does not say *which job*, *which SKU*, *which invoice line*, or *whether the refund already hit the processor*. Matching a deposit to a guess is a job. Encoding the rule so the guess is unnecessary is a different job.

Watch out.. “It syncs” is not a specification. Sync what, on which event, in which direction, and what happens when the event arrives twice?

The glue: events, not vibes

The glue starts with **events**. In Stripe’s world those are often webhooks: signed HTTP calls that say “this PaymentIntent succeeded,” “this charge was refunded,” “this invoice was paid,” depending on how you use the product. Your software’s job is not to “listen in Slack.” Its job is to:

Verify the event actually came from the processor (signature, secret, timestamp window — as the vendor documents). Store the raw event so you can replay a bad night. Decide whether this event is new or a duplicate (idempotency keys, event ids). Update *your* records: order, job, invoice link, refund record, status. Fan out to the books product only when the rule says this event is posting-worthy. Fail in a way a human can retry without double-posting.

None of that is exciting. It is the difference between a dashboard you glance at and an operation you can staff. If you skip custom software, a contractor clicking between tabs is still executing that list with a mouse. The list does not disappear because you refused to name it.

Invoices are a type, not a PDF

An **invoice** in the payments product, an **invoice** in the books product, and a **PDF your client received** can be three objects. Studios get hurt when they pretend they are one.

Typical split:

**Draft in your ops tool.** The producer built the job: dates, rooms, add-ons, internal notes that must never go to the client. **Sent invoice.** A numbered document the client can pay against. That number should be stable. It should appear in email, in the portal, and in the books. **Processor collection.** A checkout link, a card on file, a bank debit — whatever you use — that references the same invoice id. **Books invoice.** The accounting object, with items mapped to accounts the way your bookkeeper set up, not the way a developer named a database column.

A studio builds the path between those four — not “generate PDF.” Who may send. What happens if the client pays a superseded draft, if two people send two numbers for one job, or if the amount is wrong.

Partial payments are where homemade glue dies. The processor reports an amount. The books want it applied to a specific invoice. Your workflow has to say: apply, leftover as credit, leftover as a new line, or unmatched for a human. Pick one. Write it. Do not leave it in a group chat.

Refunds are a permission problem wearing a money costume

Refunds are not a Stripe button. They are a **decision** with a **side effect** in two or more systems.

A complete refund workflow answers:

Who is allowed to request a refund (producer, finance, owner)? Who is allowed to *execute* it (often a smaller set)? Is there a reason code that staff must pick (cancelled day, quality, duplicate charge)? Does the refund hit the original payment instrument only, or can someone issue a books credit without a processor refund? When the processor confirms the refund, who writes the credit memo or payment reversal in the books, and against which invoice? What do you show the client, and when?

If anyone with the Stripe login can refund, you have a shared password, not a policy. If only the owner can refund and the owner is on a shoot, someone will bypass you with a screenshot.

The software is boring on purpose: request, approval, audit log, processor call, webhook, books write, client-facing status. “Who is allowed to click refund” is the product. Two clicks must not create two refunds — the same idempotency problem as the webhook, on the way out.

SKUs, items, and the lie of similar names

Checkout has **prices** and **products**. The books have **items** (or services) mapped to income accounts. Your rate card has names humans invented on a Tuesday.

“Edit suite — 10 hours” in Stripe is not automatically the same as “Edit suite” in QuickBooks. One might include overtime. One might be a bundle. One might be a placeholder from a test mode product you never deleted.

A studio builds a **mapping table**: internal SKU → processor price id → books item id → invoice display name. Producers pick the internal SKU. Software writes the rest. One-off lines are forbidden or routed to a catch-all finance reviews. Unreviewed catch-alls make the books look “synced” while answering nothing.

Kits and extras need billable vs included vs internal-only. Internal-only lines must never reach the client PDF or create mystery income. Renaming a product in one vendor UI without updating the map is a production incident.

Customers are not one row

The person who paid with a card, the company name on the purchase order, the billing email, and the QuickBooks customer can diverge on day one.

Glue includes a **customer link**: job client ↔ processor customer ↔ books customer. “New QuickBooks customer for every Stripe customer” is a rule, often a bad one. “Match on email only” collides when two producers share an assistant’s inbox. You do not need a marketing 360. You need a refund and an invoice to land on the customer the bookkeeper already set up.

What a studio actually builds

When a hireable software studio says it will “connect Stripe and QuickBooks,” the honest scope looks like software, not a zap.

**A source of truth that is yours.** Usually a small web application: jobs or orders, line items from your SKU map, invoice state, payment state, refund state. Stripe and QuickBooks are dependencies. They are not the place staff should invent the process.

**Inbound event handling.** Webhook endpoint, verification, storage, workers, retries, dead-letter view for humans. If you cannot replay last Tuesday, you do not own the integration.

**Outbound writes with guards.** Create or update the books invoice when *your* rules say so. Apply payments when the processor event is confirmed, not when a browser tab looked green. Refunds only through your permissioned action.

**Staff UI.** The producer should not need a Stripe dashboard to see “paid.” Finance should not need to grep logs to see “refund pending webhook.” Permissions should match roles you already have: producer, coordinator, finance, owner.

**Audit.** Who sent the invoice. Who requested the refund. Which event id closed the loop. This is how you stop arguing with memory.

**Failure UX.** Processor down. Books API rate-limited. Duplicate event. Partial refund. Wrong SKU. These are screens, not “we’ll handle it.”

**What you should not build.** A second general ledger, a tax engine, card storage the processor already holds, or a robot that “optimizes” invoicing so you make more money. That last one is outside this article on purpose.

First release: one invoice path, one payment path, one refund path, one SKU map. Run beside the spreadsheet briefly. Then stop treating the sheet as the system of record.

The spreadsheet that pretends to be glue

Many teams already built the glue in a sheet: export Stripe, export QuickBooks, VLOOKUP, hope. That can limp along at low volume if one person owns it and nobody refunds on a weekend. Then two people edit, a column shifts, test-mode ids leak, and the SKU map lives in someone’s Drive.

That is not a simple setup. It is an untested system with no webhook, no idempotency, and no permissions. Replacing it is encoding rules you already execute badly under stress.

For the longer version of that failure, see [when spreadsheets become the business system](/blog/when-spreadsheets-become-the-business-system). For what not to dump into a public chatbot while you are staring at those exports, see [what not to paste into ChatGPT if you handle invoices](/blog/what-not-to-paste-into-chatgpt-if-you-handle-invoices).

How to tell if you need software vs more seats

Buy another SaaS seat when the vendor’s object model already *is* yours: one product, one invoice style, rare refunds, one owner who also does the books. A native connector plus a one-page written workflow might be enough.

Commission software when:

Jobs have many lines, many people, and a life cycle the vendor UI does not show Refunds and changes are normal, not exceptional The SKU map is real and changes You cannot afford “whoever had the login” You are already reconciling by memory

More dashboards will not encode “overnight rate cannot combine with weekend rate” or “only finance refunds after the producer files a reason.” Those are your rules. They belong in your application.

What this is not

This is not a comparison of processors as investments, not tax categorization, not scraping or “growth hacks,” and not legal advice about PCI or contracts. Use vendor docs for vendor behavior. Use a software team for jobs, roles, and what “closed” means in your studio.

If you are choosing who to hire, [types of software companies and who to hire](/blog/types-of-software-companies-and-who-to-hire) is the companion. You want people who will argue about idempotency and refund permissions, not people who install five apps and call it a platform.

Work with a studio that will build the glue

RootoverZero is a founder-led software studio. We build the unglamorous middle: internal tools, [custom software](/services/custom-software), and [web applications](/services/web-applications) around how you already take work and close it. If you are trying to stop being the human API between a payments product and a books product, start with [how we work](/how-we-work) and [onboarding](/onboarding). Bring the messy path, not a stack diagram. We would rather ship one honest invoice loop than a slide that says “fully automated.”

FAQ

If we already pay for Stripe and QuickBooks, what is left to build?

The workflow. Events into your records, invoices that mean the same thing in both places, refunds that reverse in both places, SKU mapping, and permissions. The subscriptions are inputs. They are not the operating system.

Can a native “sync” replace custom software?

Sometimes, when volume is low, the object models line up, and one person owns exceptions. The moment you have jobs, partial payments, one-off lines, or more than one person refunding, you are specifying software whether you write it down or not.

Where should invoices live?

In a system you control as the operational source, with copies or linked objects in the books product and collection handled by the payments product. Three objects with one id is safer than one PDF everyone forwards.

Who should be allowed to click refund?

A small, named role, through your tool, with a reason and an audit trail, not everyone who can open the processor dashboard. The processor button is not your policy.

What does a studio actually ship in the first release?

One direction of truth: create job → invoice → collect → mark paid in books → refund path with approval. Webhook handling, a SKU map, and a screen staff will actually use. Not a second accounting suite.

Is this financial or tax advice?

No. This is not financial, tax, or investment advice. It is about operations software and the glue between a payments product and a books product. For books policy and tax treatment, use a qualified advisor in your jurisdiction.