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. Validated against real settlement data (UK and German files, multi-currency), it reconciles to the exact deposit, to the cent.
What changed since I first posted, much of it thanks to the people in this thread:
A review bucket: every unmapped fee type, missing COGS row or ambiguous line gets flagged with severity instead of being guessed into "Other".
A go/no-go summary above the results: import blocked / margin review needed / clean preview, with deposit tie-out and journal balance. Each count expands into the exact lines to fix.
Monthly fee breakdown across settlement periods, editable journal account names, and an automated sign-direction test for facilitator tax, reimbursements, promos and reserves.
Pricing is public and checkout is live: the core tool is free during validation, and there are 10 founding seats at a one-time $49 for a lifetime Pro license (skusum.com/pricing.html). A Chrome extension is ready for founding users too.
Would love feedback, especially from anyone who sells on Amazon or does the books for sellers. If you send me a settlement file, I will run a free per-SKU teardown and send back the reconciled numbers plus the journal.
Try it in one click (demo data built in): https://skusum.com/
This is a good wedge. For bookkeepers, I'd make the first screen less about "profit by SKU" and more about "does this settlement tie out before I touch QBO/Xero?"
A simple proof pack would help: 2-3 anonymized Seller Central exports, a plain reconciliation report, and the exact journal rows that would be imported. That gives them something inspectable without OAuth or a big trust leap.
If you want an outside sanity check, I can take your demo/anonymized sample flow and write up the tie-out + journal-import edge cases I'd test.
Deal - do the sanity check, everything you need is already public: live tool with demo data at skusum.com/app, sample outputs at skusum.com/sample.html, the review bucket with fixture-backed cases at skusum.com/review-bucket.html, and the journal + mapping at skusum.com/journal.html. Write up the tie-out + journal-import edge cases you'd test, and I'll map them against what the review bucket already catches - any miss becomes a test fixture with credit to you. If your writeup surfaces failure modes we genuinely don't handle, that's exactly the kind of work I'd pay for a deeper pass on.
Pulled the public sample pages/CSVs. Quick pass: the sample journal balances (debits 15,170 = credits 15,170), the six SKU profit rows sum to 1,400, and the review bucket is doing the right thing by blocking clean export on missing COGS + an unmapped fee type.
The 5 cases I'd add first:
For the validator, I'd keep three statuses: import_blocked, margin_review_needed, clean_preview. That keeps "books tie out" separate from "SKU margin is safe to act on." Technical QA only, not accounting/tax advice.
This is excellent, thank you for actually pulling the samples and checking the numbers.
The import_blocked / margin_review_needed / clean_preview split is especially useful. That captures the distinction I'm trying to preserve: "the settlement ties out" is not the same as "SKU margin is safe to act on."
One design question: would you expect those statuses to show as a top-level bookkeeper summary before the journal, or embedded inside the affected sections/rows?
I'd do both, but the top-level summary should come first. For a bookkeeper, that summary is the go/no-go screen: deposit tie-out, journal balance, counts by status, and the exact reason export is blocked.
Then carry the same status down into the affected rows/sections with a short reason code. That lets someone decide in 10 seconds whether the journal is importable, while still giving the review bucket the exact lines to fix.
For v1 I'd put a sticky summary above the journal, with each count linking/filtering to the rows behind it.
Shipped it the way you described, same day. There is now a sticky summary above the results: status (import blocked / margin review needed / clean preview, your naming, it was better than mine), journal balance, settlement net that ties to the deposit, and severity counts that expand into the exact flagged lines with a suggested action for each. Live at skusum.com/app, the built-in demo lands on the margin review path, and a settlement loaded without orders shows the blocked path. If you ever run your 7-row synthetic file through it, I would be curious whether the statuses land where you expected. Thanks, this made the trust layer visibly better.
Quick public-route check before the fixture: skusum.com/app currently redirects to www.skusum.com/app, and that no-slash page is loading /app.js + /demo-data.js from the root, where both 404. The trailing-slash asset paths are live at /app/app.js and /app/demo-data.js, so redirecting /app -> /app/ or using absolute /app/ asset paths should fix the demo button.
After that, the 7-row fixture's expected result would be: import_blocked for the unmapped SKU/fee, deposit tie-out still visible, journal export disabled until mapping/COGS are resolved, and row-level reasons linked from the sticky summary. That would land exactly where I'd expect for a bookkeeper-facing trust screen. Technical QA only, not accounting/tax advice.
Good catch, thank you. Fixed and deployed: /app now 308-redirects to /app/, so the no-slash route loads the right assets and the demo works from both URLs.
On the fixture expectations: import_blocked for unmapped SKU/fee and missing COGS, deposit tie-out still visible, and row-level reasons from the sticky summary all match what ships now. One place I landed slightly differently: journal export is not hard-disabled on import_blocked. A settlement loaded without Orders is high severity for SKU trust, but the journal itself still balances and ties to the deposit, and books-only users legitimately export it. So the export now warns instead: it names the high-severity count and the Import blocked status, and asks for explicit confirmation before giving you the file.
If you think a hard block is still right for a bookkeeper workflow, tell me where you would draw the line. My current instinct: hard block only when unmapped fee types exist, since that is the one case where the classification itself is broken rather than incomplete.
I'd draw the same line you landed on: hard block only when the export would encode a wrong classification, not when SKU confidence is incomplete.
Unmapped fee type / unmapped account mapping = hard stop. Missing Orders, missing COGS, blank SKU, or settlement-only activity = warning + explicit confirmation if the journal still ties to the deposit and every affected line is named.
For bookkeepers, the guardrail I'd want in the export itself is a visible review sheet or header: status, high-severity count, reason codes, and "journal balances, but SKU margin is not decision-grade." That way the context survives if someone forwards the CSV later.
So: block bad/misclassified books; warn loudly on incomplete SKU margin. That keeps the books workflow usable without pretending the product-profit layer is clean. Technical QA only, not accounting advice.
Done, deployed. Export policy now matches what you described: unmapped fee types hard-block the journal (the one case where the file would encode a wrong classification), and the error names the offending line types. Missing Orders, missing COGS, blank SKU, and settlement-only still export after an explicit confirm, since the journal ties to the deposit. The review context travels inside the file too: the CSV gets trailer rows (status code, severity counts, reason codes, and "journal balances, but SKU margin is not decision-grade"), and the XLSX gets a Review status sheet as the first tab, so a forwarded file keeps its status. I drew the hard-block line only at unmapped types, per your call. If you hit a case where an incomplete-SKU warning should also be a hard stop, tell me which one and I will move it.
That review-bucket direction is the right part to pressure-test. If I were validating it for a bookkeeper, I'd use one anonymized settlement export plus a SKU-to-account/class mapping CSV and check three boring things: does settlement net tie to the expected deposit, which SKUs or fee types land in review instead of being guessed, and what journal rows would be produced for import.
I mocked a tiny synthetic version of that flow yesterday: 7 fake rows, expected deposit $78.09, calculated net $78.09, and one unmapped SKU flagged before import. No Amazon login, no bank/QBO/Xero access, no private data.
If useful, I can turn that into a narrow sample-file validator around one real anonymized file shape in 48 hours. Fixed $200-$500 depending on scope; if I can't show a working demo, no charge.
This is a useful framing, thank you.
I’m not looking to hire implementation help yet, but the validation checklist is exactly the part I care about: deposit tie-out, no guessing on unmapped SKUs/fee types, and inspectable journal rows.
If you were pressure-testing the review bucket, what 3–5 failure cases would you include first?
The local-first angle is smart, especially for finance data. A lot of small operators want better numbers but get nervous once the solution asks for logins or uploads.
I’m building a much simpler finance tracker for freelancers through WhatsApp, and I keep running into the same trust/friction tradeoff: people want convenience, but not at the cost of handing over too much access.
Are your founding users more excited about the privacy angle, or the QuickBooks/Xero export?
Good question.
My current read is: privacy lowers the first objection, but it is probably not the main reason people would keep using it.
For finance data, “no login / no upload” makes someone willing to try it with real reports. But the stronger pull seems to be the output: can it tie the Amazon settlement back to something trustworthy, surface the review bucket clearly, and produce something a bookkeeper can actually use for QBO/Xero.
So I’d frame it as:
privacy = permission to try with real data
reconciliation/export = reason to keep using it
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.
Happy to. Send it over whenever the review bucket's ready and I'll go through how the failure modes are surfaced, specifically whether a bookkeeper would trust what they're seeing at a glance. That "presented in a way people actually trust" piece is usually where these tools win or lose, so glad you're treating it as a first-class problem. Looking forward to seeing it.
Thanks again. The review bucket is ready enough to poke at now.
I tried to keep it honest rather than clever. If SkuSum cannot trust something, it should say so instead of forcing it into a clean-looking report.
Right now it flags missing Orders/COGS, unmapped fee types, account-level ads, refund timing, settlement-only/order-only SKUs, blank settlement rows, reimbursements vs COGS, transfers/disbursements, and monthly settlement breakdowns.
The main rule is: incomplete or ambiguous input should block SKU-level trust, not produce fake confidence.
You can try it here with demo data:
https://skusum.com/
Sample output:
https://skusum.com/sample.html
Journal example:
https://skusum.com/journal.html
If you have 5 minutes, I’d really value your first reaction: would a bookkeeper understand the failure modes at a glance, or is anything still too easy to misread?
Went through the sample output, journal, and landing page. This is strong work.
What lands:
The "losers you might miss" table is the killer feature. CABLE-2M looks fine on gross but bleeds -$395 after ads and COGS. That's the exact blind spot sellers have, and you lead with it.
Separating "books tie out" (the balanced journal, debits = credits) from "SKU profit needs review" is the smartest call here. Two different questions, and you don't blur them.
The journal draft asking bookkeepers 5 specific mapping questions is a great move. The clearing-account-then-bank flow is the right default.
Two things a bookkeeper might misread:
In the settlement breakdown, "Amazon Advertising: if in settlement" and "Sales Tax: when present" are correct but conditional wording sits in the amount column. A bookkeeper scanning fast might read those as zero-value lines rather than "depends on your data." A muted tag like "conditional" instead of putting it where a number goes would remove the doubt.
The COGS entry shows $4,370 tying cleanly, but it's only right if the seller's cost file is complete. Worth a visible note that COGS accuracy depends entirely on their input, otherwise a missing cost row silently understates COGS and nobody sees it.
On your core question: yes, a bookkeeper would understand the failure modes at a glance. The trust layer works. The honesty-over-polish framing is exactly right for this audience.
Glad it helped. You're building it the right way, most tools optimize for a clean-looking number and hide the gaps. Flagging what needs review instead of faking confidence is what earns bookkeeper trust. Excited to see where it goes.
This is extremely useful, thank you.
The “books tie out” vs “SKU profit needs review” distinction is exactly what I was trying to validate, so that part landing is a big signal.
Both fixes make sense. I’ll move conditional wording out of the amount column so it can’t be mistaken for a zero-value line, and I’ll add a visible COGS completeness note. The COGS number is only as trustworthy as the seller’s cost file, so missing/stale cost rows should be review items, not silent assumptions.
Really appreciate the “honesty over polish” read. That is the product direction: tie out what can be tied out, and clearly flag what still needs human review before anyone trusts the SKU margin.
Thanks, this is exactly the kind of review I was hoping for.
I’m tightening the review bucket now so it is not just a dump of exceptions. The goal is that a bookkeeper can quickly see what tied out, what did not, which lines need human review, and why they were flagged.
I’ll send a sample once that view is coherent enough to judge. I’d especially value feedback on whether the failure modes are understandable at a glance, not just technically correct.
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.
Makes sense keeping it simple early is smart. I’ll drop something in the feedback form.
On your bookkeeper question from what I’ve seen, settlement tie-out is the biggest pain point first. Bookkeepers hate when the numbers don’t match what Amazon deposited. SKU-level profit matters but usually comes second once trust in the data accuracy is established. Journal export cleanup is the time-saver that makes them actually recommend the tool to their seller clients.
That ordering is really helpful.
So the trust sequence is basically:
That makes sense. I was initially thinking SKU-level profit was the primary hook, but I’m increasingly seeing that settlement tie-out is the first trust gate for bookkeepers.
When you say journal export cleanup makes them recommend the tool, is that mostly about account/category mapping, handling weird Amazon fee types, or avoiding manual cleanup before import into QBO/Xero?
Good question it’s mostly about avoiding manual cleanup before import. Amazon’s fee types are messy and inconsistent (FBA fees, storage, referral, advertising all mixed together), so bookkeepers spend real time manually reclassifying before it’s usable in QBO or Xero. If your export already maps those fee types into clean categories, that’s the difference between ‘nice tool’ and ‘I’m recommending this to every client.’ Account mapping matters too, but fee type cleanup is where the real hours get burned.
By the way, happy to keep going deeper on this — if it’s easier, I’m on Telegram or email too.
This is really helpful, thank you.
The distinction between account mapping and fee type cleanup is a big one. I was thinking about mapping, but you’re right that normalizing Amazon’s messy fee types before import is probably where the real hours get burned.
I’d definitely like to go deeper. I avoid posting my Telegram/email publicly, but there’s a feedback section on the SkuSum site that comes directly to me. If you send a note there, I can reply properly from there.
One thing I’d love to understand: when you clean this up today, what are the worst offenders? Advertising vs referral/FBA/storage fees, reserves/adjustments, marketplace/FX lines, or something else?
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.
Nice. That sticky summary is the right move. I'd expect the built-in demo to land in margin_review_needed, and the settlement-without-orders path to land in import_blocked, so that matches the split we were aiming for.
The next fixture I'd add is specifically sign direction: marketplace-facilitator tax, reimbursements, promos, and reserve/holdback lines in one settlement. Those are the cases where the deposit can still tie and the journal can still be wrong if debit/credit direction flips.
Small note: my original synthetic file is simpler than your current demo path, so I wouldn't treat it as coverage by itself. I'd use it as a smoke test, then add that sign-direction fixture as the real pressure test.
Added it as an automated pressure test, it now runs in the suite on every change. One settlement with all four line families you named: principal 1000, marketplace facilitator VAT -80, reimbursement +25, promo coupon -40, and a reserve hold -150. The deposit ties at 755, and the test asserts the exact side of every journal line, not just the balance: sales credit only, withheld tax debit only, reimbursement credit only, promo debit only, reserve debit only, clearing debit 755. If any direction flips, the suite fails even though debits still equal credits. And agreed on your synthetic file, smoke test only. If you have other line families where you have seen direction flips in the wild, I will turn them into fixtures too.
Nice, that's exactly the kind of test that catches the dangerous version of "balanced but wrong."
I don't want to overclaim real-data coverage from the public samples, but the next two fixture families I'd add are:
Prior-period refund / chargeback: original sale is not in this settlement, but refund principal, refund admin fee, returned shipping/tax, and maybe a reimbursement are. Deposit can tie while current-period SKU margin gets distorted unless the row is marked review_needed / period_mismatch.
FX + rounding settlement: marketplace payout currency differs from books currency, with a small rounding adjustment and marketplace fee. The test should assert rounding goes to an explicit FX/rounding line, not into SKU profit or random fee income.
I'd also keep a boring "unknown new fee type" fixture forever: deposit still ties, but clean export stays blocked until the mapping is explicit.
If you want the next paid slice, I'd make it very concrete: 8-10 synthetic settlement fixtures with expected status + exact journal rows + failure note for each, no seller data needed.
On the paid slice: interested, but scope and terms belong off-thread. Drop a note through the feedback form on skusum.com with your email, and I will reply from my inbox with what makes sense at this stage.