Use case
Switch Sync Tools Without Double-Counting a Year
For businesses already syncing Stripe into QuickBooks Online some other way, who want to move to Acodei without double-counting a year of revenue or discovering a structural setting too late to change it cheaply.
14-day free trial · card required · cancel anytime
Who this is for
- +You already sync Stripe into QuickBooks Online with another tool, a spreadsheet import, or a bank-feed workflow.
- +Your QuickBooks file already holds Stripe records that Acodei did not write.
- +You are picking a cutover date and want to know what happens on each side of it.
- +You would rather make the structural decisions before the first sync than discover them after a month of records.
The problem
Choosing a new sync tool is the easy half. The half that goes wrong is the switch itself, because your QuickBooks file is not empty. It already holds a year of Stripe activity that something else created, and that history does not announce itself to whatever you connect next.
Two questions decide how this goes, and neither is about features. What will the new sync do about records it did not write? And which setup choices are cheap to change later versus expensive?
Get those wrong and the failure mode is specific and unpleasant: a period where every Stripe charge exists twice in your books, once from the old tool and once from the new one, with nothing flagging it. Revenue that is double counted does not announce itself the way missing revenue does. It ties out, it looks plausible, and it is found at year end.
The records your old tool wrote are invisible to the new sync
This is the single most important thing to understand before you pick a cutover date, and it is usually assumed to work the other way around.
Acodei's duplicate protection tracks what Acodei synced. It works by setting the QuickBooks document number on records Acodei creates to the Acodei transaction id, so that a re-sent Stripe webhook collides with the existing record instead of writing a second one. That is a strong guarantee, and it is scoped to records that carry that id.
A sales receipt your previous tool created does not carry one. Neither does a record from a CSV import, a line added from the bank feed, or an entry someone keyed in by hand. None of them are visible to the check at all. So the sync is not going to look at January, recognise that your old tool already booked it, and skip it.
The practical consequence is that the boundary between old and new is yours to enforce rather than the sync's. Pick a date, know which system of record owns everything before it, and make sure the new sync is not asked to write the same period again.
Decide the holding account before the first sync, not after
The holding account is the QuickBooks account that stands in for your Stripe balance, and it decides the shape of nearly every record that follows. On Undeposited Funds, payouts arrive as itemized Deposits that sweep the underlying payments. On a regular asset clearing account, payouts arrive as a single Transfer for the net amount.
It is also the choice that is most expensive to revisit, and the mechanics say so plainly. The one-shot permission to change the holding account is granted only while a connection has zero transactions at synced status across all of its Stripe accounts, and it is revoked once a transaction reaches synced status. Changing it after that is handled as a migration rather than as a settings change.
A switch is the one moment when this costs you nothing. You are already making structural decisions, your connection has not synced anything yet, and the permission is in the state where the choice is unrestricted. Every week you run on the wrong one makes the correction larger.
The reconciliation method comes with the choice, which is the part people do not expect. A clearing account supports comparing the QuickBooks balance against the Stripe balance, daily if you want it. Undeposited Funds supports matching each payout against the bank feed instead. If your reason for switching tools is that you could never reconcile properly, that is the decision that fixes it rather than the vendor.
Your existing QuickBooks customers are an asset, not an obstacle
A year of syncing has left customer records in QuickBooks, and the common fear is that a new tool will ignore them and create a parallel set.
That is not what happens, and the reason is worth knowing precisely because it tells you what to check. When Acodei syncs a transaction, it resolves the customer by name: first against its own record of customers it has already mapped, then by querying QuickBooks for a customer whose display name matches. The match is case-insensitive but otherwise character for character. If it finds one, the transaction is attributed to that existing customer. If it does not, a new one is created.
So customers your previous tool created get reused, as long as the name Stripe sends matches the display name already in QuickBooks exactly. Where switchers get surprised is when the old tool used a naming convention of its own, appending an identifier or reformatting a company name, because then nothing matches and you get a second customer next to the first.
The check is worth five minutes before you cut over. Open a handful of customers your old tool created and compare them against the name on the matching Stripe customer. If they differ, you know it now instead of after your customer list has doubled. Acodei does not update customer records after it maps them, and there is no way to pair a Stripe customer with a QuickBooks customer by hand, so names are the whole mechanism.
Backfilling history is a separate decision from cutting over
These two get run together and they are not the same question. Cutting over is about where new Stripe activity lands from a given date. Backfilling is about whether you go back and rebuild the period your old tool already handled.
The case for leaving history alone is that it is already booked, already reconciled, and already closed. The case for backfilling is consistency: one record shape across the whole year, which matters more if the old tool summarised where you now want detail, or if you never trusted its output in the first place.
What you should not do is decide it implicitly. Backfilling into a period your old tool already wrote is precisely the situation the first section describes, where nothing on either side recognises the other. If you want both, the sequence matters: settle which records own the period, remove the ones that do not, then backfill into the gap you have deliberately made.
What Acodei recognises, and what it does not
Acodei recognises its own work. Duplicate protection sets the QuickBooks document number on records Acodei creates to the Acodei transaction id, so a redelivered Stripe webhook collides with the record already there rather than writing a second one. While that is on, the document number field is carrying the id rather than being available for your own numbering.
Acodei does not recognise records it did not write. A record from another sync tool, a CSV import, the bank feed, or a person carries no Acodei transaction id, so the duplicate check cannot see it. That boundary is the reason a cutover date is a decision you make and enforce rather than a setting you turn on.
Customers are the exception to that pattern, and in your favour. Customer resolution queries QuickBooks by display name, so customers your previous tool created are matched and reused when the names agree exactly.
Want to see this on your own Stripe data?
Start a free trial14-day free trial · card required · cancel anytime
What you need in place
- +A holding account decided before the first transaction syncs. The permission to change it freely is granted only while a connection has zero transactions at synced status, and is revoked once a transaction reaches synced status.
- +A cutover date you enforce yourself, because records written by another tool, a CSV import, the bank feed or a person carry no Acodei transaction id and are not visible to duplicate protection.
- +Customer display names in QuickBooks that match the names Stripe sends, if you want existing customers reused rather than duplicated. Matching is case-insensitive but otherwise character for character.
- +A decision on whether Duplicate Protection stays on, since it uses the QuickBooks document number field on records Acodei creates.
Frequently asked questions
Will Acodei duplicate the Stripe records my previous tool already created?
Not by re-writing them on its own, but it also cannot detect them. Duplicate protection is scoped to records Acodei wrote, which it identifies by the Acodei transaction id it puts in the QuickBooks document number. A record another tool created carries no such id and is invisible to the check. Duplicates in a switch come from asking the new sync to cover a period the old one already booked, so the protection against that is your cutover date rather than the feature.
Do I have to delete what my old tool wrote?
Not necessarily. It is a bookkeeping decision about which system of record owns each period, and the sync will not make it for you. Leaving a closed, reconciled period alone and starting the new sync from a clean boundary is the lower-risk option. Rebuilding the year for consistency is legitimate too, as long as you remove the old records for that period first rather than layering new ones on top.
Will my existing QuickBooks customers be reused?
Yes, where the names match. Customer resolution checks Acodei's own mapping first, then queries QuickBooks for a customer whose display name matches the name from Stripe, case-insensitively but otherwise character for character. A match attributes the transaction to that existing customer. A mismatch creates a new one, which is why a previous tool's naming convention is worth checking before you cut over.
What if I pick the wrong holding account during the switch?
It is correctable, but it stops being cheap quickly. The permission to change it freely exists only while a connection has zero transactions at synced status, and it is revoked once a transaction syncs. After that the change is handled as a migration rather than a settings change. Switching tools is the one moment when the decision costs nothing, which is the argument for making it deliberately rather than accepting a default.
Can I keep using my own document numbers in QuickBooks?
Not on records Acodei creates while Duplicate Protection is on, because that field is where the Acodei transaction id lives and is what makes a redelivered webhook collide instead of duplicating. For most Stripe-first businesses the field is doing more good as a collision guard than as a counter, since card-payment sales receipts are not documents anyone numbers by hand. If you genuinely need the field, that is a real constraint to raise rather than work around.
What customers say about running Stripe through Acodei
“If you're testing out all the different Stripe/QuickBooks integration apps right now, let me save you some time. This one is the best one by far.”
“Works well and is really helpful for massive transactions. The support is really fast and helpful. 100% recommended.”
Ready to try Acodei?
Connect Stripe to QuickBooks Online in minutes and let the fees, refunds, and payouts land where your accountant expects them.
14-day free trial · card required · cancel anytime