Why PayoutPrep Says a Stripe Payout Can't Go Into QuickBooks as One Line

I am a solo developer, and I first ran into this problem while reconciling a Stripe payout by hand. The payout that landed in the bank was already net of everything, Stripe had taken its processing fee out of every charge, and refunds and disputes had been subtracted too. When I tried to enter that payout into QuickBooks, the numbers would not match to the cent, because QuickBooks needs to see gross sales and fees as separate lines, and a single net payout hides all of that. I had to split every transaction by hand, each charge into a gross line and a fee line, each refund and dispute into its own entry, before the books made sense. I looked for a converter that would do this automatically and keep every balance transaction as its own row, so that gross minus fee equals net on every single line. The tools I found either imported only the payout total or netted everything together, which is exactly what makes the books wrong. So I built PayoutPrep, it reads the Stripe balance transactions, splits each one into gross and fee, and writes a QuickBooks-ready CSV where every transaction, refund, dispute and adjustment keeps its own row.

On growth, the honest answer is that nothing has worked yet. I have not found a channel that brings users to PayoutPrep. The one thing that produced any response at all was the SaaS Browser listing, I claimed the product there in early November, the listing was boosted to the top of the site's search results, and that visibility led to an invitation to write this case study. But even that has not brought a single paying customer, so I would not call it a method that works, it brought attention, not users. The method that completely failed was promoting on X. I post on X every day, but the account has almost no followers, so a post about PayoutPrep reaches nobody. There is no audience to click, no engagement, and no signups from it. The posts go out and nothing comes back. I have learned that posting into an empty room is not marketing, and that a product with no distribution needs a channel where buyers already look, which is why the directory listing, even with its small result, is the only thing I would try again.

There are no complaints, because there are no users yet. PayoutPrep has zero paying customers, and I have no users writing in, so nobody has written in to say something is broken or missing. The support inbox has received no complaints at all. The only inbound question I have had was not a complaint but a pre-sales question on the SaaS Browser listing, from someone asking how partial refunds, disputes and multiple adjustments on Stripe payments are handled. My answer is in the product itself, every balance transaction becomes its own row in the CSV, split into gross and fee, so a partial refund, a dispute and its fee, and an adjustment each appear as their own line instead of being netted away. That is how I handle questions, I answer them myself, directly, and I point at what the tool actually does. When real users arrive and complain about something, I will fix it the same way, read the message, reproduce the problem, and change the product. Until then there is nothing to fix, and I will not invent complaints to sound busy.

Most people assume a Stripe payout can be imported into QuickBooks exactly as it arrives in the bank. It cannot, and that is the mistake almost everyone makes. A payout is already net of everything, Stripe takes its fee out of every charge, and refunds, disputes and adjustments are subtracted before the money moves. If you import the payout total as one line, your books understate gross sales, because the revenue you actually earned was larger than the payout, and the fees disappear as if they never happened, which means your expenses are understated too. The tax picture is wrong in both directions at once. What clean books actually need is every balance transaction kept as its own entry, split into a gross line and a fee line, so that gross minus fee equals net on every single line. A partial refund has to be its own row, a dispute has to be its own row together with its fee, fifteen dollars in the United States, returned if you win, and an adjustment has to be its own row as well. Only then does the sum of the rows reconcile with the payout to the cent, and only then can a bookkeeper trust the numbers. The product exists because the obvious way is wrong.

The next steps depend on user feedback, and that is a deliberate choice, not a lack of a plan. I will wait for real users, listen to what they ask for, and build that first instead of guessing at features nobody wants. Until the feedback arrives, I will keep the free tier running, keep the site up to date, and keep the tool working on real Stripe exports. If users ask for more accounting software beyond QuickBooks, or for handling more transaction types, that is what I will build next. The order is fixed, users first, then features.

PayoutPrep launched in October 2026 as a Stripe-to-QuickBooks converter. It has 0 paying customers and $0 MRR so far; the free tier covers 30 transactions, paid plans run $0–$19 a month with a 14-day free trial, and no one has upgraded yet.

I had never worked in accounting before PayoutPrep, and I had never built a bookkeeping tool. What I had done was build small products on my own. I started as a solo developer making in-browser utilities, which became YuliusBox, a set of about two dozen privacy-first tools that run entirely in the browser without uploading files. I also built several Android apps, including a password vault, a printing app and a packing app, and I learned how to ship, how to fix what real users report, and how to keep a product alive after launch. None of that was accounting, so for PayoutPrep I learned the bookkeeping side from Stripe's own documentation and from the way QuickBooks expects imported data to look. I checked the converter's output line by line until gross minus fee equalled net on every row, and the totals matched the payout to the cent. PayoutPrep was my first product for sellers and bookkeepers, and it came out of combining the two things I knew, building small tools, and the bookkeeping rules I had to learn.

My biggest mistake was leaving empty placeholder variables for the Telegram token, chat ID and admin secret in wrangler.jsonc, the deployment config for PayoutPrep. Every time I deployed, the config file overwrote the real secrets stored in the Cloudflare dashboard with empty values. Nothing failed loudly, the deploy itself succeeded, the site stayed up, and there was no error to notice. What broke, quietly, was the Telegram payment notification and the admin page, which both depend on those secrets. The failure was silent, and the damage only showed up later, when the payment notifications and the admin page stopped working. The fix is to delete those three variables from wrangler.jsonc entirely and put the real values back in the Cloudflare dashboard, so a deploy can never overwrite them again. What I learned is to keep secrets only in the dashboard, never put placeholder variables in a config file, and never trust a green deploy on its own, after deploying, I check that the live product still behaves the way it should.