Glossary

QuickBooks Journal Entry

A QuickBooks journal entry is a manual transaction that posts debits and credits straight to accounts, without a business document like an invoice or a bill behind it.

Also called: journal entry, JE, manual journal entry, general journal entry, adjusting entry, debits and credits

Definition

Every other form in QuickBooks is a business document first. An invoice is something you sent a customer. A bill is something a vendor sent you. A sales receipt is a sale that happened. The accounting is derived from the event: you describe what occurred, and QuickBooks works out the debits and credits.

A journal entry inverts that. Intuit defines it as "a manual accounting transaction used to adjust balances or move money between accounts without using standard forms like invoices or bills." There is no document behind it. You are writing the accounting itself.

That is exactly what makes it powerful, and exactly what makes it the wrong default. A journal entry can move any amount between any two accounts, which means it can express things no form can. It also means nothing about it is checked against a real-world event, because there is no event to check it against.

The one mechanical rule QuickBooks does enforce is balance. In Intuit’s words, "the total of the Debits column must equal the total of the Credits column." That catches arithmetic mistakes. It does not catch a correctly balanced entry posted to the wrong accounts, which is the error that actually costs people time. Intuit’s own guidance is blunt about it: "if you are unsure about which accounts to debit or credit, consult your accountant to avoid errors in your financial records."

For anyone syncing a payment processor, the practical question is not how to write one. It is why a good sync writes so few of them.

Key points

  • +Records debits and credits directly, with no invoice, bill, or receipt behind it.
  • +QuickBooks enforces one rule: total debits must equal total credits.
  • +Balance is not correctness. A balanced entry posted to the wrong accounts still saves cleanly.
  • +Best used for adjustments and corrections, not for recording ordinary business activity.
  • +Intuit directs you to name the customer or vendor on lines that touch A/R or A/P.
  • +Acodei writes a journal entry in exactly one documented case: daily-batched Financial Account expenses.

What QuickBooks actually asks for

The form is deliberately bare, which is the first clue about what it is for.

Intuit’s steps are short: select **+ Create**, then **Journal entry**. On the first line pick an account and enter the amount in either the **Debits** or the **Credits** column. On the next line pick the other account and enter the same amount in the opposite column. Add a **Memo** if you want to explain yourself later, confirm the two column totals match, and save.

Notice what the form never asks. It does not ask who the customer was, what was sold, when it shipped, or what it cost. Those questions belong to the forms that describe events. The journal entry asks only which accounts moved and by how much.

There is one place that changes. On a line posted to Accounts Receivable, Intuit’s instructions tell you to "select the customer from the dropdown list in the Name field", and on an Accounts Payable line, to "select the Vendor from the dropdown list in the Name column". That is because A/R and A/P are not really single accounts. They are the totals of per-customer and per-vendor subledgers, and a line that lands in the control account without a name attached leaves those two views disagreeing.

When a journal entry is the right tool

The honest test is whether a document exists.

If money genuinely moved and something happened in the world, there is almost always a form that describes it, and using that form gives you the audit trail, the subledger, and the reports for free. A sale is a sales receipt or an invoice. A cost already paid is an [expense](/glossary/quickbooks-expense). Money moved between two accounts you own is a [transfer](/glossary/quickbooks-transfer).

If nothing happened in the world and you are correcting how something was already recorded, that is journal entry territory. Reclassifying a cost booked to the wrong account. Recording depreciation. Accruing something at period end. Opening balances. These have no document because they are not events; they are accounting.

The failure mode is using a journal entry because it is faster. It is faster. It is faster because it skips the parts that were doing work for you.

Why a journal entry is a poor way to record processor activity

It is tempting to reduce a day of Stripe activity to one balanced entry. Debit the bank, credit sales, debit fees, done. The numbers tie out and the books balance.

What that entry throws away is everything except the numbers. No customer is attached, so nothing reaches your customer reports. No product or service is named, so income never splits by what you actually sell. If you later need to know which sale produced a fee or which customer generated a refund, the entry cannot tell you, because that information was never in it.

There is a reconciliation cost too. A journal entry can post to a bank or clearing account, but it does not carry the shape of the underlying deposits, so matching it against what the bank actually received turns into arithmetic rather than a tick-off.

None of this makes journal entries bad. It makes them the wrong tool for recording activity that has perfectly good documents available.

Journal entry vs the daily summary

These two get conflated constantly, because both compress a day of activity into one record.

They are not the same thing. A summarized sync can still use real documents, so a day of sales can arrive as a sales receipt with product lines, tax, and a customer, rather than as raw debits and credits. The compression is in how many records you get, not in whether the records describe anything.

That distinction is worth holding onto when comparing sync tools. "One entry per day" and "one journal entry per day" sound alike and are meaningfully different: the first is about volume, the second is about losing the document layer. If the daily record is a journal entry, the detail is gone regardless of how neatly the totals tie.

Where Acodei uses a journal entry, and where it deliberately does not

Acodei writes journal entries in exactly one documented situation, and the boundary is worth stating in both directions.

**Where it does.** When a connection’s expense batch interval is set to daily, Stripe Financial Account spending stops producing one record per event. An `outbound_payment`, which is money sent to a vendor, contractor, or other external recipient, and a `received_debit`, which is typically spend on a Stripe-issued card, would each normally create their own Purchase or Expense paid from your Stripe Financial Account holding account. Under daily batching they collapse into a single journal entry per account per day instead. The per-event behavior is the default "instantly" mode, so if you are seeing one daily journal entry where you expected individual purchases, that setting is the reason.

**Where it deliberately does not.** Uncommon balance transactions are the case people expect journal entries for, and Acodei does not use them. Disputes and chargebacks are **not** recorded as per-dispute journal entries or itemized expense lines. Neither are reserves, Connect transfers, Capital, or Climate contributions. Each type is mapped once, under Balance Transaction Mapping on the Account Mapping page, and Acodei’s documentation is explicit that these "need to be explicitly mapped" and that Acodei "will then process these balance transactions in the daily balance summary or upon payout, depending on your settings". On a non-Undeposited-Funds holding account they land on the daily balance summary; under Undeposited Funds they are reflected on the payout deposit itself.

The mapping is a product rather than a raw account: for each balance transaction type you add a product, either backed by a new chart-of-accounts entry or pointed at one you already use. Acodei’s docs are clear that which type maps to which product is "entirely up to you and your accountant". If a payout fails to sync because a type was never mapped, adding the mapping and resyncing the deposit is the fix.

Two details on the Financial Account path are worth knowing before you go looking for them. Stripe fees charged on transfers and outbound payments are recorded separately, as part of a Daily Balance Summary for Financial Accounts that is distinct from the regular daily balance summary used for the Stripe payments balance. And Acodei currently cannot retrieve the recipient name for outbound payments, so those purchases are assigned to a default vendor named "Stripe". Stripe has confirmed the issue and is working on a fix.

Want to see this on your own Stripe data?

Start a free trial

Frequently asked questions

What is a journal entry in QuickBooks Online?

Intuit defines it as a manual accounting transaction used to adjust balances or move money between accounts without using standard forms like invoices or bills. It posts debits and credits directly, so there is no underlying business document describing what happened.

Do debits and credits have to match on a QuickBooks journal entry?

Yes. Intuit states that the total of the Debits column must equal the total of the Credits column, and QuickBooks will not save an unbalanced entry. Worth remembering that balancing only proves the arithmetic is consistent, not that the accounts are right.

When should I use a journal entry instead of an invoice or an expense?

Use a journal entry when you are correcting or adjusting how something was recorded rather than recording an event. Reclassifications, depreciation, accruals, and opening balances have no document behind them. If a real transaction happened, the matching form gives you the audit trail and subledger detail that a journal entry cannot.

Why does QuickBooks ask for a customer or vendor on some journal entry lines?

On lines that touch Accounts Receivable or Accounts Payable, Intuit instructs you to select the customer or the vendor in the Name field. Those accounts are the totals of per-customer and per-vendor subledgers, so a line posted without a name leaves the control account and the detail reports out of step.

Does Acodei record Stripe disputes as journal entries?

No. Disputes and chargebacks are not recorded as per-dispute journal entries or itemized expense lines. They are mapped once under Balance Transaction Mapping, and from there appear on the daily balance summary on a non-Undeposited-Funds holding account, or are reflected on the payout deposit itself under Undeposited Funds. The same applies to reserves, Connect transfers, Capital, and Climate.

Why do I see one daily journal entry instead of individual Stripe expenses?

Because the connection’s expense batch interval is set to daily. In that mode, outbound payments and received debits do not each produce their own Purchase or Expense; they collapse into one journal entry per account per day. The default instantly mode is what produces the per-event records.

Is a daily summary the same as a daily journal entry?

No, and the difference matters when comparing sync tools. A summarized sync can still write real documents, so a day of sales can arrive as a sales receipt carrying products, tax, and a customer. A daily journal entry carries only debits and credits. Both compress volume; only one keeps the detail.

What customers say about running Stripe through Acodei

Stripe Verified Partner BadgeQuickBooks Intuit Badge
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.
RyanOwner at Indie Music Academy
Works well and is really helpful for massive transactions. The support is really fast and helpful. 100% recommended.
AndresCo-founder and CEO at Kanguro Collections and Reinsurance

Ready to try Acodei?

Connect Stripe to QuickBooks Online in minutes and let the fees, refunds, and payouts land where your accountant expects them.