A Missing Stripe Daily Summary, and How to Find It

Your Stripe account did business on the 14th. QuickBooks shows nothing on the 14th.

Before you resync anything, it is worth knowing that "my daily summary is missing" is three different questions wearing one sentence, and that two of the three usually resolve to something that is not a fault at all. A day with no summary is not the same as a day with no activity, and a summary that posted with a total you did not expect is a different problem again from one that never posted.

This post is the diagnosis. Which record you are actually looking for, why it might legitimately not exist, what Acodei checks on its own before you get involved, and what to do when the day really is missing.

Stop hand-keying Stripe activity into QuickBooks. Acodei syncs charges, refunds, fees, payouts and disputes into QuickBooks Online with the accounts and the dates already correct. Start a free trial.

"Daily summary" is three different records

This is the part that makes the diagnosis non-obvious, and it is the reason two people can look at the same account and disagree about whether anything is wrong.

Acodei produces three distinct daily mechanisms. They are easy to confuse because all three write day-dated records against a holding account, and in conversation all three get called the daily summary. Internally they are separate, each with its own job.

The day-group receipts. These belong to accounts running in daily summary mode. A payout's balance transactions are aggregated into per-day, per-currency groups, and each group becomes one record: a Sales Receipt when the day nets positive, a Refund Receipt when it nets negative, deposited to the resolved holding account for that currency.

The balance activity summary. This is a single Sales Receipt per day carrying aggregated fees and other Stripe balance activity, and it is the one people mean when they describe finding an entry labelled as an Acodei daily summary. The important thing about it is that it is not exclusive to daily summary mode. Accounts on real-time sync get these too.

The financial account daily record. If you use a Stripe financial account, its fees and currency conversion have their own daily job, separate from both of the above and pointed at a different holding account.

So the first question is not "why is my daily summary missing". It is "which of the three am I looking for", because the answer changes what counts as missing.

The most common answer: nothing was missing

Start here, because on a real-time account this explains more absent summaries than every other cause combined.

The balance activity summary does not sweep up the whole day. It walks the day's balance transactions and skips anything that already has its own transaction record. Only activity with no per-transaction record of its own lands on the summary: standalone fees, adjustments, uncommon balance types.

Follow that through. On a real-time account, a day on which every charge and every refund synced individually, and nothing unusual happened to the balance, has nothing left for the summary to carry. No summary is produced, and that is the design working rather than failing.

This is the difference between an empty day and a missing day, and it is worth being precise about it because they look identical in QuickBooks. Both are a date with no summary against it. One means there was nothing left to record. The other means something was left to record and it did not get there.

The way to tell them apart is to stop looking at QuickBooks and look at the day's balance activity in Stripe. If everything on that day has a corresponding individual record already in your books, the day is complete. If there are fees or adjustments on that day with nothing representing them anywhere, you have a real absence.

A day-group receipt follows the payout, not the calendar

Accounts in daily summary mode have a different reason for a day to be absent, and it is a timing reason rather than an error.

The day-group records are built from a payout. A payout event runs the aggregation, which sorts that payout's balance transactions into per-day, per-currency groups and writes a record for each group. The day's receipts are derived from the payout that covers the day.

That has a consequence people rarely anticipate on their first month. Activity from a day that no payout has covered yet has not been grouped yet. The business happened; the record that summarizes it is downstream of a payout that has not arrived. If your account pays out on a rolling two-day schedule, the last two days of any period will routinely look empty in a way that resolves itself without anyone doing anything.

So on a daily summary account, check the payout before you check the sync. If the payout covering the 14th has not landed, the 14th has not been grouped, and there is nothing missing yet. This is also why the payout schedule and the clearing account matter more in this mode than most people expect: the payout is not just a deposit, it is the trigger for the records that explain the deposit.

When the total is wrong rather than absent

A different complaint, and a more interesting one. The summary posted, and the number is not what you expected.

Two documented behaviors produce a legitimate difference between what you would compute by hand and what the summary carries. Neither is an error, and both are settings you can look up rather than mysteries.

Fees may not be on the summary at all. This one applies to the balance activity summary specifically. Stripe fees are split into two categories following Stripe's own balance transaction taxonomy. Transactional fees are the fee field on a charge, payment or refund. Non-transactional fees are standalone fee balance transactions: Stripe fees, network costs, application fees, and adjustments in the fee reporting category, which is where Billing, Radar and Tax product fees live.

A setting on the account routes each of those two categories either onto the summary as line items, or into a separate Purchase. Three combinations are allowed: transactional, non-transactional, or both. So a summary that looks short by exactly your fee total is not short at all. The fees are on a Purchase, because that is what the account is set to do. We wrote about that split in detail in the piece on non-transactional fees.

A pending charge is deliberately not in there. When the daily scan encounters a pending charge, an ACH payment still settling being the usual case, Acodei does not bake an unsettled amount into the day's summary. It creates an individual transaction for it and dispatches the real-time job instead.

The pending state is then tracked across the pipeline. The charge is marked succeeded when its webhook confirms settlement. If it fails instead, the entry is reversed on the failure date and re-included as a summary line item.

Read that last sentence slowly, because it is the one that produces confusing books. Money that failed in March can appear on a March summary line even though the original charge belonged to February, and the reversal is dated to the failure rather than to the original. A declined or failed payment moves a number between two months without anything being wrong.

Acodei checks its own arithmetic

Here is the part most people do not know exists, and it changes how you should treat a suspicious day.

A daily summary is a derived record. It is arithmetic performed on a set of balance transactions, and arithmetic can be checked. So summaries are not trusted on creation. Acodei re-derives the day's expected totals directly from Stripe balance history, and compares them against what was actually recorded.

Two details in that sentence carry the weight.

It re-derives from Stripe rather than from its own copy. That is what makes it a check rather than a restatement. A validation that recomputed from the same stored rows that built the record would agree with itself no matter what.

And it respects the account's own time zone and its sync mode. That matters more than it sounds. A day is not a universal boundary. A summary built on UTC boundaries for an account reporting in Pacific time would misplace every transaction in an eight-hour window at each end, in both directions, which nearly cancels out across a year and is exactly why that class of error survives to an audit. The comparison is run on the account's own time zone, so the two sides are describing the same day.

The validation runs as its own job on its own queue, dispatched by a sweep that looks for days that failed validation or never got written. A support utility can run the same validation on demand for a specific case.

This pairs with something we published separately. The argument for pulling your own Stripe report through the Reporting API is that it gives you an independent check on your books, and the warning in that piece is that the time zone has to line up on both sides before a variance means anything. This is the same comparison, run internally, with the time zone already lined up. Your report and this validation are two instruments pointed at the same question, which is why they should agree, and why a disagreement between them is informative rather than annoying.

Opening a summary that did post

If the record exists and you want to know what is inside it, you do not have to reverse engineer it from the total.

Line items are persisted per summary, which is what feeds the Data Feed and gives the record an audit trail. The summary record itself also carries a private note identifying it as an Acodei daily summary for that date, which is how you find it in QuickBooks when the register is dense and everything on screen is dated the same day.

That combination is what turns "the total is wrong" from an argument into a lookup. You can see which balance types were grouped, and what each group contributed.

When the day really is missing

You have ruled out the empty day, the payout that has not arrived, the fee routing and the pending carve-out. The activity exists in Stripe, nothing represents it in QuickBooks, and you want it fixed.

The Data Feed is where this happens, and it is worth understanding what it is before using it. It is the user-facing ledger of every synced, pending and errored transaction, each with its status and, when something went wrong, its error message. The status is the diagnosis, and several of the values are more specific than people expect.

A transaction sitting at sync failed has an error message attached, and the message usually names the cause directly: a deleted fee product, a customer conflict, a validation mismatch. Fix the underlying cause first. Resyncing before the cause is fixed just reproduces the same failure.

A transaction at payout pending is waiting on other transactions to sync first. Nothing is broken. There is an ordering dependency in progress, and the absence you are looking at is the queue rather than a failure.

A transaction at half-synced is the interesting one. It means the QuickBooks entity was created but the job died before finishing, so the record is parked deliberately rather than retried, specifically so a retry cannot produce a duplicate. If you see this, the thing you must not do is create the missing record by hand, because a QuickBooks-side duplicate is a much worse problem than a half-finished one.

Resync is the repair. It deletes the QuickBooks side of the transaction and runs it through its sync job again, which also picks up any mapping, fee-method or tax settings you have changed since the record was first written. Settings are never applied to historical records on their own, so resync is also the mechanism for making an old record reflect a new configuration.

One rule that is worth more than the rest of this section: resync from the Data Feed rather than hand-editing the QuickBooks record. Manual edits break the linkage Acodei uses for reconciliation and reversal. A hand-corrected record looks right today and stops being correctable later, which is how a single missing day turns into a reconciliation discrepancy that outlives the person who created it.

A diagnosis in order

Put together, the sequence is short.

1. Decide which record you want. Day-group receipts, the balance activity summary, or the financial account daily record. They are three different mechanisms and a missing one means three different things.
2. Check whether the day had anything left to summarize. On real-time sync, a day whose activity all synced individually produces no balance activity summary by design.
3. On daily summary mode, check the payout. The day-group records derive from a payout, so a day no payout has covered has not been grouped yet.
4. If the total is the complaint, check the fee routing and the pending charges. Fees may be on a Purchase instead of the summary, and a failed pending charge reverses on the failure date rather than the original one.
5. Open the Data Feed and read the status. Sync failed, payout pending and half-synced are three different situations with three different responses.
6. Resync from the Data Feed, never by hand.

Frequently asked questions

How do I tell a missing day from a day with no activity?

Look at the day in Stripe, not in QuickBooks, because both look identical from the QuickBooks side. The balance activity summary only carries activity that has no individual record of its own, so on a real-time account a day where everything synced per charge legitimately produces no summary. If every balance transaction on that day is already represented somewhere in your books, nothing is missing. If there are fees or adjustments with nothing standing for them, you have a real gap.

Why is there no daily summary for yesterday?

On daily summary mode, the most likely reason is that no payout has covered yesterday yet. The day-group records are built from a payout, so they follow the payout rather than the calendar. On real-time sync, the likeliest reason is that yesterday had nothing left over for a summary to carry.

Does Acodei check its own daily summaries?

Yes. Each summary is validated against Stripe rather than trusted on creation. The validation re-derives the day's expected totals from Stripe balance history and compares them against what was recorded, respecting the account's own time zone and its sync mode, and a sweep dispatches that validation for days that failed it or were never written.

Why does my daily summary total not match the fees I expected?

Most likely because the fees are not on it. Stripe fees are split into transactional and non-transactional categories, and a per-account setting routes each category either onto the summary as line items or into a separate Purchase. Check which of the three allowed combinations your account uses before treating the difference as an error.

Can I see which transactions went into a daily summary?

Yes. Line items are persisted for each summary, which is what the Data Feed reads, so you can see the groups and what each contributed. The record in QuickBooks also carries a private note identifying it as an Acodei daily summary for that date, which is the fastest way to find it in a crowded register.

What does the half-synced status mean?

That the QuickBooks entity was created but the job died before finishing. The record is parked on purpose so that a retry cannot create a duplicate. Do not key the missing record in by hand when you see this, because a duplicate in QuickBooks is a harder problem to unwind than an incomplete record.

Should I fix a missing day by entering it in QuickBooks manually?

No. Use resync from the Data Feed. A hand-entered record has no linkage back to the Stripe transaction, which is what Acodei uses for reconciliation and for reversing an entry later, so a manual fix removes your ability to correct the record automatically from then on.

The takeaway

A missing daily summary is a detectable condition, not a mystery, and most of the time it is not missing.

The reason it feels mysterious is that one phrase covers three different records, and two of them can be legitimately absent for reasons that have nothing to do with a failure: the day had nothing left to summarize, or the payout that produces the day's records has not arrived. Rule those out first and the remaining cases are small, specific, and visible in the Data Feed with a status attached.

Underneath all of it, the summary is arithmetic on balance transactions, re-derived from Stripe and checked against what was written, on your account's own time zone. That is what makes the question answerable at all.

Let the entries take care of themselves. Acodei posts Stripe charges, fees, refunds, payouts and disputes into QuickBooks Online on the right dates and in the right accounts, and validates its own daily summaries against Stripe rather than asking you to. Start a free trial or see how the reconciliation works.