Built a local-first Amazon profit-by-SKU + QuickBooks/Xero journal tool. Looking for founding users.
Most Amazon sellers stitch Orders, Settlement, Ads and COGS in a spreadsheet that breaks every month, and even Amazon's own reports disagree with each other. So I built SkuSum: it joins those reports right in your browser (nothing uploaded, no Amazon login) into one reconciled profit-by-SKU file, plus a balanced QuickBooks/Xero journal your accountant can import.
Local-first by design: your financial data never leaves your machine, and you can verify every number against the source report.
I just validated it against real settlement data (UK and German files, multi-currency) and it reconciles to the exact deposit, to the cent.
Free lifetime for the first 10 who help shape it. Would love feedback, especially from anyone who sells on Amazon or does the books for sellers.
Try it in one click (demo data built in): https://skusum.com/
Local-first for seller financials makes a lot of sense — most Amazon folks I know don't want their margin data sitting in someone else's cloud
How are you handling the QuickBooks/Xero sync — official APIs both ways, or one-way export?
Thanks. Right now it's deliberately one-way: SkuSum generates a balanced journal file (CSV) that you or your bookkeeper import into QuickBooks or Xero. No OAuth, no API connection in either direction, and that's on purpose. The moment I add a cloud API I take custody of settlement data and inherit SP-API throttling and deprecation, which is exactly the fragility sellers complain about with existing tools. If there's real demand I'd look at a direct push later, but the import file already drops in cleanly. Are you on QBO or Xero, and do you book it yourself or hand it to a bookkeeper?
That's such a. thoughtful risk-mitigation design choice. Third-[arty finance APIs always bring endless throttling, breaking changes and data liability headaches, offline VSV export is way more stable for bootstrapped seller tools
I’ve seen many small merchants avoid SaaS finance tools entirely over data privacy fears, your local-first approach hits a really underserved pain point
I don’t handle Amazon books myself, but will pass this along to seller friends who struggle with messy spreadsheets each mouth
Thanks, I appreciate that.
The local-first choiice is mostly about trust. Sellers are already dealing with sensitive Amazon financial data, so I do not want the first step to be “connect your accounting system and upload everything to another SaaS.”
If you do pass it along, the best fit is someone who still checks Amazon profit in spreadsheets or has trouble tying SKU profit back to settlement/accounting totals.
Happy to send them a simple example output if useful.
Nice, SKU-level profit is exactly where most sellers are flying blind. Curious how you're handling the QuickBooks sync: real-time or batch? The reconciliation edge cases (refunds, fees posting late) are usually where these tools live or die. Built a few integrations like this and that's always the hard part.
Good question. Batch by design, one journal per settlement statement, not real-time. On the edge cases you flagged: because SkuSum reads the actual settlement flat file (what truly hit the bank), a fee or refund that posts late just lands in the period it posted, and each statement reconciles to its exact deposit. Nothing silently disappears, it shows up where Amazon actually booked it. Refunds as contra-revenue, fees split by type. Where have you seen these tools break, the late-posting fees or the mapping?
Smart call going batch off the settlement file, that's the version that actually reconciles. Where I've seen these break is the mapping, specifically when sellers operate across multiple marketplaces or currencies, or when Amazon changes a fee type and the journal silently miscategorizes it until someone notices the books don't tie out. The settlement-file approach handles the timing cleanly; the mapping is where the ongoing maintenance lives. Are you locking the mapping to fixed fee types, or letting users remap when Amazon introduces new ones? That flexibility tends to be what separates a tool people trust long-term from one they abandon after the first surprise.
That is exactly the risk I am trying to avoid.
The plan is not to silently force every Amazon fee into a fixed category. Unknown or changed fee types should show up as unmapped/review-needed, so the seller or bookkeeper can decide where they belong before exporting the journal.
For the first version, I am thinking:
Does that match how you would expect a trustworthy workflow to behave, or is there another failure mode you have seen with marketplace/currency mappings?
That's exactly the right architecture, the "unmapped / needs review" section is the piece that earns trust, because it's honest about what it doesn't know instead of guessing. One failure mode I'd plan for: FX timing on multi-currency. The fee gets charged in one currency but you book in another, and if you use the settlement-date rate vs the transaction-date rate they won't tie out, sometimes by enough to matter at year-end. Deciding which rate you standardize on (and showing it) saves a lot of "why is this off by $4" later. The other one is Amazon reserving funds across settlement periods, money held in one statement and released in the next can look like a discrepancy if each statement is treated as fully closed. Your tie-out-before-export rule probably catches most of it, but those two are where I'd stress-test.
This is exactly the kind of failure mode I was hoping someone would point out.
I’m going to add both of these as stress-test cases:
My instinct is to keep the first version conservative: show the FX basis used, flag timing-sensitive lines, and avoid pushing anything ambiguous into the journal without review.
The reserve issue is especially useful. I don’t want a statement to look “wrong” just because Amazon carried cash across periods.
When I have a sample journal export with the review bucket visible, would you be open to sanity-checking the structure? Not asking for deep testing, just whether the failure modes are presented in a way a seller/bookkeeper would actually trust.
The local first angle removes the biggest objection Amazon sellers have about financial tools nobody wants their settlement data on someone else’s server. The real challenge is reaching Amazon sellers who are serious enough about margins to care about SKU level reconciliation. Curious how you’re planning to find your first 10 beyond IH?
That's the real question. Beyond IH: warm, question-first DMs in seller and ecommerce-bookkeeping communities (asking how people currently reconcile, not pitching), bookkeepers who run Amazon clients since they feel this monthly and refer their sellers, and a couple of seller subreddits. Optimizing for 10 people who actually reconcile, not raw signups. How did you find your first serious users?
Honestly still building that pipeline myself I help founders with exactly this part so I’ve been in the trenches testing what works. The bookkeeper angle is smart, they feel the pain monthly and have multiple Amazon clients they can refer. That’s a multiplier most founders miss. Are you on Telegram, Discord or email? Would love to connect and compare notes on what’s converting.
Thanks. I am keeping the contact flow simple for now because this is still very early and not fully validated yet.
The bookkeeper angle is exactly what I want to test: sellers may feel the pain occasionally, but bookkeepers feel it evry month across multiple Amazon clients.
Best way for now is to use the feedback form on the site with a few notes on what you are seeing convert. If it looks relevant, I will get your email from the form and reply from my inbox.
I am especially interested in whether bookkeepers care more about SKU-level profit, settlement tie-out, or journal export cleanup.
The "reconciles to the exact deposit" part is what stood out to me. For finance tools, trust comes from being able to verify every number, not just generating reports. I also like the local-first approach—it fits the sensitivity of financial data really well.
Appreciate that, the verify-every-number part is the whole point. Every figure traces back to a settlement line you can open, and the journal balances debits to credits to the deposit. Reports you can't audit are why sellers don't trust these tools. Are you selling on Amazon yourself, or building in the space?
Neither. I spend most of my time evaluating the strategic decisions founders make around positioning, trust, and adoption.
Your point about auditable trust vs. reporting is interesting. I have a couple of observations that are easier to explain over email than in a thread.
What's the best email to reach you?
IH doesn't really do DMs, and I'd rather not post my email in a public thread. Easiest: there's a feedback form on skusum.com, the feedback section near the bottom. Drop your note there and add your email, and I'll reply directly if it's something I want to dig into.
Just sent it over to the email address listed on the SKU Sum website.
Looking forward to hearing your thoughts once you've had a chance to read it.
Thanks, Aryan. I replied by email.
The distinction is useful. For now I am keeping SkuSum focused on reconciliation / verification rather than becoming a full financial source of trutth. The next useful signal is still seller/bookkeeper workflow feedback.