Dejan

Turning card transactions into clean, accountant-ready books – receipts, categories, and an automatic sync to QuickBooks.

Product case study · Role: Product Manager · Domain: B2B Fintech / Spend Management

TL;DR I led expense management capabilities for business customers: receipt capture, transaction categorization, and a two-way integration with QuickBooks Online so that card spend flows into the general ledger automatically. The goal was to eliminate manual bookkeeping from card spend – every transaction arrives in QuickBooks coded, documented, and reconciliation-ready. After launch, most connected businesses saw the bulk of their card spend land in QuickBooks with no manual re-entry, cutting hours from month-end close.

The problem

For small and mid-size businesses, the card is the easy part – the bookkeeping is the pain. Owners and office managers spend hours every month chasing receipts, categorizing transactions, and re-typing card activity into their accounting software. Errors slip through, month-end close drags on, and accountants bill for cleanup work that software should have prevented.

Since the vast majority of small businesses in the US run on QuickBooks, the highest-leverage move was clear: make card spend land in QuickBooks correctly, automatically, and with the receipt attached.

What we built

• Receipt capture – snap a photo or forward an email; the receipt is matched to the right transaction automatically using amount, date, and merchant matching, with a one-tap manual pick for ambiguous cases.
• Smart categorization – transactions are coded against the business’s own chart of accounts, with rules and memory (“always code Delta to Travel”) reducing repeat work.
• QuickBooks Online sync – a secure OAuth connection pulls the chart of accounts from QuickBooks and pushes categorized transactions, receipts, and payment records back on a schedule the customer controls.
• Policy hooks – flags for missing receipts and uncategorized spend, so admins chase exceptions instead of reviewing everything.
• Multi-user context – combined with employee cards, every expense arrives attributed to the person who spent it.

How it works

The flow

An admin connects QuickBooks once, via OAuth. We import their chart of accounts and let them map defaults: which account card spend posts to, how payments are recorded, and how categories translate. From then on, employees just spend and snap receipts. Transactions are categorized (by rule, by suggestion, or by hand), and the sync engine posts finalized transactions to QuickBooks with the receipt attached as documentation.

Key product decisions

• Sync settled, not pending. We only push settled transactions to the ledger. Pending authorizations change (tips, partial captures, reversals) and pushing them early creates exactly the reconciliation mess we were trying to eliminate.
• The customer’s chart of accounts is the source of truth. We categorize into their accounts rather than forcing our taxonomy onto their books. This one decision drove most of the integration’s complexity – and most of its value.
• Exceptions-first admin UX. Admins should not review 500 clean transactions to find 12 problem ones. The default view is “what needs attention.”
• Fail loudly, never silently. If a sync fails or a mapping breaks (e.g. an account was deleted in QuickBooks), the admin is told exactly what happened and what to fix. Silent sync failures destroy trust in the entire product.

Under the hood (for the engineers)

• QuickBooks Online API integration. OAuth 2.0 connection per business, with token refresh handling, per-entity rate limiting, and idempotent writes so retries never create duplicate entries in the ledger.
• Sync engine. A state machine per transaction: settled, categorized, queued, posted, verified – with reconciliation between our records and what QuickBooks reports back. Edits after posting generate updates, not duplicates.
• Receipt matching. Uploaded receipts are parsed (amount, date, merchant) and matched to candidate transactions; ambiguous matches fall back to a one-tap manual pick.
• Refunds, credits, and disputes. Negative amounts, partial refunds, and disputed transactions all need correct accounting treatment – the long tail that separates a demo from a product accountants trust.

My role

• Owned the problem discovery: interviewed business owners, office managers, and accountants to map the month-end workflow and its failure points.
• Defined the integration scope and the mapping/settings model, working through accounting-correctness questions with finance-savvy customers and advisors.
• Specified sync behavior for the hard cases: refunds, edits after posting, disconnects, and chart-of-accounts changes.
• Drove the launch and the activation funnel – connect rate, mapping completion, first successful sync – working with a squad of six engineers, a designer, and QA.

Challenges and trade-offs

• Accounting correctness is unforgiving. A UX bug annoys a user; a books bug shows up at tax time. We biased toward conservative behavior and human confirmation anywhere money categorization was ambiguous.
• Third-party API constraints. Rate limits, occasional outages, and API quirks meant the sync engine needed to be resilient by design – queues, retries, and idempotency everywhere.
• Serving two personas. The employee wants zero friction; the admin/accountant wants completeness and control. Every flow was designed twice, once for each.

Results

• About 40% of active business customers connected QuickBooks within six months of launch.
• Over 85% of transactions on connected accounts synced to QuickBooks with no manual touch.
• Customers reported saving multiple hours per month at close, and QuickBooks-connected businesses churned noticeably less than unconnected ones.

What I learned

Integrations are products, not plumbing. The engineering connects two APIs; the product manages trust between a business’s money and its books. The features that mattered most were not the clever ones – they were the ones that made the system’s behavior legible: clear sync status, loud failures, and an audit trail an accountant could believe.