Sticky Books/the posting engine
Borrowed from RevParPro

Post to QuickBooks
like it can never be wrong.

A2X fires a journal and hopes. RPP already posts to QuickBooks for the hotels with real discipline: the suggested account comes from your own past books, the post is a claim that verifies itself, and nothing goes live until an independent source agrees. This is that model, applied to Sticky.

Already proven in RPP. The hotels post to QBO this way today. We are not inventing it, we are porting it.
01
The suggestion

Onboarding does the heavy lifting

You do not map settlement by settlement. When a seller connects, Sticky reads their whole QuickBooks history and builds the entire map at once, then they approve the batch. After that, almost nothing stops. Only a charge Amazon newly invents needs a person.

Onboarding, done once

Connect QuickBooks and Amazon. Sticky maps everything from your history before your first settlement even posts.

History read
18 months
Recurring charges mapped from your books
47
Need a quick look
3
One timeApprove the batch and your recurring charges are done. 44 were unanimous, 3 flagged for a glance.
WhyThis is the derive step run across your entire history at once, not per settlement. RPP builds each hotel's whole map the same way before it ever posts a night.
Case A: how each recurring charge is decided

Where "FBA Monthly Storage Fee" landed in your QuickBooks the last 4 months

Jun 2026220 Warehousing, Amazon FBA Storage$1,204.60
May 2026220 Warehousing, Amazon FBA Storage$1,142.30
Apr 2026220 Warehousing, Amazon FBA Storage$988.75
Mar 2026220 Warehousing, Amazon FBA Storage$1,050.20
Your books say File it under 220 Warehousing, Amazon FBA Storage, same account and side as every prior month. 100% consistent
WhyEach of the 47 is decided this way during onboarding: majority account and side from your own books. Commission, referral, pick and pack, storage all recur, so they map with no guessing and never stop you again.
Case B: later, the only thing that stops

"AWD Inbound Convenience Fee", Amazon adds it in July, no history to lean on

No prior entry exists in your books. Own-history cannot answer this one. This is the real reason it stopped for you.

So it falls back, in order:

1 · Your booksYour other inbound / AWD fees already post to your 501strong
2 · The networkSellers everywhere classify this new Amazon fee as inbound-freight cost of goodsthe kind
3 · StickyIn your chart, that role is account 501your account
4 · YouOne tap to confirm, and it becomes your own historyrequired
The network never sees your chart of accounts. Everyone's accounts and numbers differ and keep changing. What sellers share is what a new Amazon charge is, never where anyone files it. Sticky translates that kind to the account in your own books that fits.
Best guess, needs you Points to 501 COG, Shipping + Supplies, but because it is new, you sign off once before it posts.
WhyThe shared signal is the category, never your accounts. And because a chart changes, Sticky binds each mapping to what an account IS, its role, not its number, and re-reads your chart continuously. RPP classifies every account the same way, so a rename or renumber never breaks a mapping.
02
The post

A claim that verifies itself, not fire and forget

The dangerous moment is the write. RPP never just POSTs. It reserves the slot first, posts, then reads back to confirm, and unwinds cleanly if anything fails.

1
Claim the slot
Reserve this settlement + period before touching QuickBooks. Two runs cannot double-post.
unique lock, pending
2
Post to QuickBooks
Send the balanced journal to the right company file, checked by realm and name first.
writes once
3
Read it back
Confirm the entry exists with the returned id, then promote the claim to posted.
verified
If the post fails at any point, the claim is deleted and the settlement returns to the queue. No half-written books, ever.
WhyThis is a two-step commit. The unique lock is what actually stops a cron run and a human click from posting the same settlement twice, a class of bug A2X-style tools hit constantly.
03
The gate

Seven checks before anything goes live

RPP refuses to post unless every gate passes. The most important one is independent: the journal must agree with a source the settlement file itself cannot fake.

1
Nothing unmapped
Every line has an account, or it waits.
2
Debits equal credits
Balanced to the cent.
3
Mapping is approved
A person blessed this account, on record.
4
Ties to the Amazon deposit
Journal matches the cash that actually landed.
5
Amounts are reasonable
Inside the normal range for this seller.
6
Right company file
Realm and name checked before the write.
7
No sign contradiction
History does not imply the opposite entry.
!
Any fail holds the post
The settlement stays in the queue, named.
WhyThe tie-out to the real deposit (gate 4) is the one A2X and ConnectBooks do not enforce as a hard stop. It means Sticky cannot post books that disagree with the money that hit your bank.
04
The approval

Approval that cannot silently rot

In RPP, changing where an account maps automatically un-approves it. You cannot quietly re-point a mapping under an old blessing. Every change is logged and cannot be edited away.

Mapping created for AWD Inbound Convenience Fee
Aug 03 · approved: no · awaiting review
Approved to 501 COG, Shipping + Supplies
Aug 04 · by the bookkeeper · posting unlocked
Someone re-points it to 220 Warehousing
Aug 09 · approval automatically revoked · posting locked until re-blessed
WhyThis closes the quiet-drift hole: a mapping cannot be changed and keep its old approval. The audit log is append-only, so the trail cannot be edited after the fact.
05
The watch

Drift watch, every day

Even after posting, RPP compares its own account totals against QuickBooks' own numbers daily and flags any account that diverges, catching accountant reclassifications the parse would otherwise miss.

Sticky says, 501 COG
$11,240.60
QuickBooks says
$11,240.60
Divergence
$0.00
WhyBooks drift after they post: a CPA reclasses something, an entry gets edited in QuickBooks. A daily compare against QuickBooks own totals means you find out the next morning, not at tax time.

What Karl builds

Port the RPP posting discipline into Sticky Books. The logic largely exists in RPP to borrow.

  1. Onboarding bulk-map, then exceptions only: at connect, derive the full map from the seller's whole QuickBooks history and bulk-approve it. After that a never-seen charge falls to a sibling rule, then a required sign-off, then becomes history.
  2. A canonical Amazon-fee taxonomy as the shared spine: the network agrees on what each Amazon charge IS (its category), never on account numbers. Sync each seller's chart, classify every account by role, and map category to the seller's own account by role, so a rename or renumber never breaks it. This is RPP's USALI-over-CoA pattern, rebuilt for Amazon fees.
  3. Claim-first posting: reserve, post, read back, promote or unwind. A unique lock per settlement.
  4. The gate stack: mapped, balanced, approved, tied to the Amazon deposit, reasonable, right company, no sign contradiction.
  5. Auto-revoke approval: any mapping change un-approves it; append-only audit.
  6. Daily drift watch: compare Sticky account totals to QuickBooks own numbers, flag divergence.
The one thing NOT to copy: RPP's thin edge-function posting path is effectively dead (an undefined variable throws before it posts). Build on the daily-journal pipeline model, not that endpoint.
Proposed posting model for Sticky Books · by Woz · Sep 1 2026
Modeled on RevParPro's live hotel QBO posting pipeline. Figures illustrative.