The Accounting Export Nobody Reconciles: Wiring a Food Hub Into QuickBooks, Xero, Stripe and a CRM

Why the standard accounting export breaks at the second producer

A food hub is not one merchant selling its own goods. It is a marketplace where one customer payment fans out to eleven producers, a commission line, a delivery charge, a packaging deposit and two or three VAT rates. Standard e-commerce accounting exports assume a single seller, so they collapse that fan-out into one sales figure and lose the payable side entirely.

The practical symptom is familiar. The export lands in QuickBooks or Xero as a daily sales receipt, revenue looks enormous because it includes money the hub is only holding on behalf of growers, and the bookkeeper then manually creates purchase invoices for each producer from a separate payout report. That is the second data entry job. It is invisible in demos because demos use one producer and one VAT rate.

The fix is not a better CSV. It is deciding, before any connector is built, what the hub is in accounting terms: an agent collecting on behalf of producers, or a principal buying and reselling. Those two models produce completely different ledgers from the same order, and getting it wrong means every export afterwards is reconciling to a number that was never going to match.

Agent or principal: the one decision that determines every integration after it

Under the agent model, the hub's revenue is only its commission and delivery fee. Producer money is a liability, not income. Under the principal model, the hub buys from producers and resells, so the full basket value is revenue and producer invoices are cost of goods sold. Pick one, write it down, then build exports to match.

The agent model usually keeps the profit and loss statement honest for a co-op that never takes ownership of the goods. A basket of 380 euros of produce plus 42 euros of commission shows as 42 euros of revenue and 380 euros sitting in a producer payable account until settlement. It also means the hub's turnover figure stays small, which matters for VAT registration thresholds in some jurisdictions and can matter for grant reporting.

The principal model is simpler to explain to a high-street accountant and is often forced on you anyway if the hub sets retail prices, absorbs unsold stock, or issues the customer a receipt in its own name for the whole basket. The cost is that your revenue line now includes money that was never yours to keep, and margin analysis requires a matching producer cost line for every single order. Whichever you choose, the platform must be able to emit both sides consistently, and your accountant should confirm the choice before go-live, not during the first VAT return.

Agent: revenue = commission + delivery + fees. Producer share = liability. Producer settlement = clearing the liability, not an expense.
Principal: revenue = full basket. Producer share = purchase invoice booked to cost of goods sold.
Mixed reality: some hubs are principal on their own-brand boxes and agent on marketplace lines. That is legitimate but needs two separate account mappings, not one toggle.

Which records actually cross the boundary, line by line

Six record types need to reach the accounting system, and only six: customer sales with VAT split by rate, producer settlements, commission and fee income, delivery and packaging charges, payment processor fees and payouts, and refunds or credits. Everything else, including order lines, stock declarations and route data, stays in the platform.

The discipline is to send summaries, not transactions. A hub running 400 orders a week does not need 400 invoices in Xero. It needs one daily or weekly sales journal broken down by VAT rate and revenue account, one settlement run posted as producer bills, and one Stripe payout reconciled against a clearing account. That keeps the ledger small enough for a human to audit and keeps the API call volume inside free-tier limits.

Refunds and deposits are where most exports quietly fail. A refunded punnet of strawberries has to reverse the customer sale, reverse the producer's share if the settlement has not run yet, or create a deduction on the next settlement if it has. A returned crate deposit is not revenue at all, it is a refundable liability that should sit in its own account and unwind when the crate comes back. If the export treats deposits as sales, the ledger slowly accumulates income that will never be earned.

Customer sales journal: gross by VAT rate, per settlement period, with a reference back to the platform batch ID.
Producer settlement: one bill per producer per run, with the platform's settlement number as the bill reference.
Commission and fees: hub income, booked separately from delivery and from packaging.
Payment processor: gross charges, processor fees as an expense, payouts against a bank clearing account.
Refunds and credits: credit note against the original batch, plus a settlement deduction if the producer was already paid.
Deposits: balance sheet liability, never revenue, unwound on crate return or forfeited after a stated period.

Stripe, Stripe Connect and the money that is not yours

Stripe reconciles cleanly only if you treat its payouts as bank transfers from a clearing account, never as revenue. Charge the customer, book the gross amount to a Stripe clearing account, book the processor fee as an expense, then match the bank deposit against the clearing balance. The difference between gross sales and bank deposit is fees and timing, nothing else.

Stripe Connect is tempting because it can split a payment to multiple connected accounts automatically. For most food hubs it is the wrong tool, and the reason is timing rather than technology. Producer amounts are not final at checkout. A grower who declared 12 kilos of courgettes and delivered 9 changes the split after the money has already moved. Substitutions, short deliveries, quality rejections and weight-based items all settle after the pick and pack, so a split-at-checkout model forces you into reversals and negative balances on grower accounts.

The pattern that holds up is: take one payment to the hub, settle producers on your own cycle from the platform's settlement run, and pay by bank transfer or batch payment file. Connect earns its place when producers need to be paid at checkout speed, when local rules push the money flow out of the hub's account for regulatory reasons, or when the hub genuinely never wants funds touching its balance. Otherwise the operational cost of reconciling hundreds of micro-transfers exceeds the benefit. If you do use Connect, model application fees, transfer reversals and negative balance handling before the first live weekend, not after.

The CRM question: what a food hub actually needs from HubSpot or a mailing list

Most food hubs need email segmentation and a wholesale pipeline, not a CRM. Shoppers are already fully described inside the platform by their order history, so pushing them into HubSpot or Pipedrive duplicates data that goes stale immediately. The genuinely useful CRM sync is narrow: restaurant and retail accounts, and marketing consent for newsletters.

Wholesale is different from retail because it has a sales cycle. A restaurant is a lead before it is a customer, someone chases it, there are pricing conversations, credit terms and a named contact who can churn. That belongs in a CRM or a deal pipeline. Household shoppers do not have a sales cycle, they have a basket frequency, and the platform already knows it better than a CRM ever will.

For marketing, sync a small consented segment to the email tool and keep it one-directional. Push email address, consent flag, order recency, basket frequency and pickup location. Do not push line-item purchase history into a third-party tool unless your privacy notice covers it and you have a reason beyond curiosity. Every field you copy out is a field you now have to delete twice when someone exercises a deletion request, and a field that can contradict the platform the moment a shopper changes their address.

Which integrations are not worth building, and what to do instead

Skip any integration where the volume is low, the data is ambiguous, or the failure mode is silent. That usually rules out real-time two-way accounting sync, inventory sync with producers' own systems, ERP connectors for a ten-person operation, and automated logistics APIs for a two-van route. A scheduled export plus a person who checks it beats a fragile live connector.

Two-way sync deserves special suspicion. The moment an accountant can edit a producer bill in Xero and the platform can also edit it, you have two sources of truth and a conflict resolution problem nobody wants to own. Keep the platform authoritative for anything derived from orders and settlements, and let the accounting system be authoritative for everything downstream: journals, tax returns, bank reconciliation, payment runs.

The test for building anything is simple. Estimate the manual minutes per week the integration removes, multiply by 50, and compare against the cost of building it and the cost of investigating it the three times a year it silently stops. A weekly settlement export that saves four hours of re-keying is worth automating. A live CRM sync that saves someone a copy and paste twice a month is not, and it will quietly desynchronise until someone emails the wrong list.

Worth it: scheduled sales journal and producer bill export to QuickBooks or Xero.
Worth it: payment processor payout reconciliation against a clearing account.
Worth it: one-directional consented email segment sync.
Usually not: real-time two-way accounting sync, producer-side stock sync, ERP connectors, carrier APIs for short local routes, automated bank payment initiation without a human approval step.

Key Takeaways

Decide agent versus principal accounting before building any export. It determines whether producer money is revenue or a liability, and every downstream mapping depends on it.
Only six record types need to cross the boundary: sales by VAT rate, producer settlements, commission and fees, delivery and packaging, processor fees and payouts, and refunds or credits.
Send periodic summaries, not per-order invoices. One sales journal and one bill per producer per settlement run keeps the ledger auditable by a human.
Stripe payouts belong in a clearing account, never in revenue. Stripe Connect's split-at-checkout model fights the reality that producer amounts change after pick and pack.
Avoid two-way sync. Keep the platform authoritative for order-derived data and the accounting system authoritative for journals, tax and bank reconciliation.

The settlement run these exports depend on is broken down line by line in our anatomy of a producer payout, which walks through splitting a €38 vegetable box between 11 growers, commission, deposits and VAT.

Frequently Asked Questions

Can QuickBooks or Xero handle multi-producer payouts natively?

Not as a marketplace. Both can record producer bills and clear them in a payment run, which is all you need, but neither can calculate the split from an order. The platform must produce the settlement, including commission, deposits, delivery share and VAT treatment, and then hand the finished producer bills to the accounting system as payables.

How often should a food hub export to its accounting system?

Match the export cycle to the settlement cycle, which for most hubs means weekly or fortnightly. A weekly sales journal plus a weekly batch of producer bills gives the bookkeeper a predictable rhythm and keeps the ledger small. Daily exports add noise without improving anything unless you are reconciling cash daily.

Do producers need to issue their own invoices to the food hub?

It depends on the model and local tax rules. Many co-ops use self-billing, where the hub generates the producer invoice from the settlement run and the producer agrees to it in writing in advance. That is far more reliable than waiting for 38 growers to send correctly numbered invoices, but self-billing arrangements usually need a signed agreement and correct VAT handling, so confirm the requirements with your accountant.

What happens to the accounting export when a customer is refunded after producers have been paid?

The customer sale is reversed with a credit note, and the producer's share becomes a deduction on their next settlement rather than a clawback. Your platform should carry that deduction forward automatically with a reference to the original order so the producer can see why their payout dropped. If the producer is not at fault, for example a delivery failure, the hub absorbs it and the deduction never reaches the grower.

Is a CSV export good enough, or do I need a real API integration?

For most food hubs under a few thousand orders a month, a well-structured CSV that maps cleanly to your chart of accounts is genuinely good enough and far easier to audit when something looks wrong. Move to an API connector when the re-keying is costing hours per week or when the bookkeeper is making transcription errors. The value is in correct mapping, not in the transport method.