Switch back to main site : Click Here
.png)
Last updated May 14, 2026 · 14 min read · By Jonah Rice, Founding Account Executive, FinOptimal
Journal entries are the manual override of accounting: the entries you make when QBO's automatic transaction posting can't get the books where they need to be. Most teams know how to create one in the interface. Fewer know how to handle the recurring ones, the batched ones, and the ones that need to update from a spreadsheet without rekeying. This guide covers all three.
QuickBooks Online supports journal entries three ways, with different ceilings. Manual entries through the + New → Journal Entry form are fine for one-offs and corrections. Recurring journal entries handle predictable templates: same accounts, same amounts, same schedule. Automated journal entries via Google Sheets handle the larger category that the first two cannot: batch entries that change each period, formula-driven amounts that update from raw data, payroll allocations, intercompany entries, and the same workbook supporting every month of the year. Most accounting teams need all three, but the third is where the most time gets saved and where most teams underinvest.
Most teams need all three modes. Manual entries cover the exceptions, recurring handles the templates, and automated handles everything else, which is usually the largest bucket.
A journal entry in QuickBooks Online is a direct posting to the general ledger that bypasses the normal transaction flow. Most activity in QBO does not require journal entries: invoices, bills, expenses, payments, and so on all post to the GL on their own as a side effect of recording them. Journal entries exist for the cases where that normal flow does not fit the work.
The four categories I see most often: corrections (an expense was coded to the wrong account, and you need to move it without deleting the original transaction), period-end accruals and deferrals (revenue or expense that needs to land in a different period from when the cash moved), allocations (one expense that needs to be split across multiple classes, departments, or entities), and reclassifications (moving balances between accounts as part of a financial review). All of these have the same shape: two or more lines that debit and credit specific accounts, with no inventory items, no customer-facing documents, no taxes, just GL impact.
One useful way to think about it: if QBO has a built-in transaction type for what you are doing, use the built-in type. Journal entries are the catch-all for everything QBO doesn't have a built-in type for. That framing matters because it tells you when to reach for a journal entry and when not to. Invoicing a customer via journal entry instead of an invoice strips out the customer-facing detail QBO needs for reports, AR aging, and downstream automation to work correctly.
The path in QBO: click the + New button in the top-left, then under Other, click Journal Entry. The form opens with a few fields at the top and an empty grid of lines below.
The fields that matter:
The grid below has one row per line of the entry. Each row needs:
Add lines with the Add Lines button at the bottom of the grid. Remove lines by clicking the trash icon on the right side of the row. The running total at the bottom shows whether debits and credits balance; they must, before QBO will let you save.
Once balanced, Save and close posts the entry and closes the form. Save and new posts the entry and opens a fresh form for the next one. The journal number increments. The entry appears in Reports → For my Accountant → Journal, and is visible in the audit log.
One detail that matters more than it should: the Description field on the line is where any downstream automation will read from. If you ever plan to use the recognition layer to spread the entry across periods, the "for the period" phrase goes in Description, not Memo. The header Memo is metadata; the line Description is what tools read.
QBO has a native recurring-transaction feature that supports journal entries among many other transaction types. The path: gear icon in the top-right → Recurring Transactions → New → Journal Entry. The form looks similar to a regular journal entry with a few extra fields at the top for the template.
The template fields you set: a name for the template, the type (Scheduled, Reminder, or Unscheduled), the frequency (daily, weekly, monthly, yearly), the start and end dates if Scheduled, and how many days in advance to create. Below that, you build the entry the same way you would a one-off journal entry: accounts, amounts, descriptions, names, classes.
What this is good for: entries that hit the same accounts with the same amounts on a predictable schedule. Standard monthly software subscriptions posted as a journal entry. Fixed-amount allocations from a parent entity to a sub-entity. A recurring set of accrued expense entries that always net to the same number.
What it is not good for: any entry where the amounts change. Payroll allocations where the totals shift each pay period. Revenue allocations that depend on actual usage data. Accrual entries where the underlying period or amount changes. Multi-entity intercompany entries where the rates float. As soon as the amounts are not fixed, the template stops being useful and you are back to editing each occurrence by hand, which defeats the purpose.
I treat the native recurring feature as good-for-what-it-is-good-for, which is a narrower band than most teams think on first encounter. The cases where amounts genuinely never change are real but limited. The much larger category of work that looks recurring (entries that post every month on a schedule, just with different numbers) falls outside what the native feature can do.
The pattern I see across accounting firms and in-house finance teams is consistent. Teams start with manual journal entries because the volume is manageable. The volume grows. The manual workflow does not scale linearly with volume: it scales worse than linearly, because each manual entry creates an opportunity for error, and reconciling errors across dozens of entries becomes its own job.
The common failures: typos on amounts (a transposed digit on a $48,000 entry costs hours to find), wrong account picks (a similar-named account chosen from the dropdown by accident), missing classes or locations (entries that work for the GL but break the departmental P&L), and the broader problem of nobody being able to audit what changed between this month's entries and last month's because there is no underlying record outside QBO.
The other failure mode is harder to measure but possibly more important: rekeying. A team that builds a workpaper in a spreadsheet each month, calculates the accrual schedule, and then types the resulting numbers into QBO journal entries is doing the work twice. The spreadsheet is the source of truth. The QBO entry is a manual transcription of the spreadsheet. Any time anyone updates the spreadsheet, the QBO entry has to be retyped. That is the work most close-cycle automation is actually replacing.
The automated method for journal entries works by treating a Google Sheet as the source of truth and posting the entries to QBO from there. The same workbook supports every month of the year. The same template handles every entry type the team uses regularly. The team's day-to-day work begins and ends inside spreadsheets, where accountants are already most comfortable.
To make this workflow possible, FinOptimal built Booker. Booker is a live sync between Google Sheets and QBO, and the Lite tier is sufficient if you're just looking to automate journal entries (the Unlimited tier supports all other transaction types, as well as additional features).
When you begin using Booker, FinOptimal provides Sheets templates to help you get started. Every row in the journal-entry sheet from those Booker templates has an Entry Label column. The Entry Label controls two things at once: which rows post to QBO, and how rows are grouped into journal entries.
The rules: a row with a populated Entry Label syncs to QBO. A row with a blank Entry Label is skipped. Each unique combination of Entry Label and date produces one journal entry in QBO, posted as EntryLabel_Date. For example, an Entry Label of Payroll with date 2025-01-31 posts as journal entry Payroll_2025-01-31.
That sounds simple, but allows for a lot of useful flexibility. You can leave blank rows between entries for visual readability; they are skipped. You can add helper rows for subtotals, check totals, or notes; also skipped. You can have a "Payroll" entry and a "Rent" entry on the same date; they post as two separate journal entries because the Entry Labels differ. Multiple debit and credit lines with the same Entry Label and date roll into one journal entry. The Entry Label is the gate.
The mindset shift that unlocks the real value is that you can build one workbook that supports every month of the year, not a new workbook each close. With this, you have two tabs at minimum. A raw data tab holds whatever data the entries depend on (payroll register exports, revenue data, expense reports), with a column that identifies which month each row belongs to. A journal-entry tab references the raw data with formulas, filtered to the current period.
Each month: paste the new month's raw data onto the raw tab. The journal-entry tab's formulas pick up the new data automatically. Click Book. The entries post. Same workbook next month, no rebuild. Teams that ran three workbooks a month (one for payroll, one for revenue allocations, one for intercompany) used to manage thirty-six separate files a year. The continuous-workbook workflow turns that into three files total.
The key discipline: the journal-entry tab should reference the raw data with smart formulas (VLOOKUP, INDEX-MATCH, SUMIFS keyed off labels or dates), not with hardcoded cell references like =Raw!C7. Hardcoded references break the moment the raw data changes shape. Smart formulas adapt.
The Debit and Credit columns in the sheet are just spreadsheet cells. They accept any formula. Standard practice: amounts come from a SUMIFS that references the raw data tab, filtered by month and category. When the raw data changes, the amounts change. When you paste the new month's data, the formulas recalculate.
This is the leverage point that turns the sheet from a transcription tool into an automation tool. A payroll allocation that pulls department codes from the payroll register and SUMIFs the totals by department is an entry that builds itself when you paste the register. A revenue allocation that references a payment processor export and applies a percentage split across classes is the same. The team's work shifts from "calculate, transcribe, review" to "paste, glance, run."
One mechanic worth knowing about specifically because it surprises new users: deleting a row from the Booker sheet does not delete the corresponding journal entry from QBO. The row is gone from the sheet, but QBO still has the entry that was posted previously.
To remove a previously-synced entry from QBO, write "delete" in each amount cell (replacing the debits and credits that were posted), keep the Entry Label and date the same as the original, and run Booker. The tool finds the matching entry in QBO by Entry Label and date, sees the delete values, and deletes the entry. The mechanic only works on workflows configured for Create and Update; Create-Only workflows cannot delete because they do not modify after sync.
After Booker runs successfully, every row that posted gets an X in the Hold column automatically. The default behavior is "do not let me accidentally re-run a row I already processed." When the team is ready to process a new month, the workflow is to load the new data, populate Entry Labels for the new rows, and run. Old rows stay on Hold; only new rows process.
This is what makes the continuous-workbook method actually work month-to-month without rebuilding. Old months sit there with Hold flags. The current month's new rows are the only ones the tool acts on. The historical record stays in the workbook for reference.
One workflow that combines two of the tools in the FinOptimal stack is worth calling out specifically, because the integration produces compounding value.
If a Booker journal entry includes the phrase "for the period" in the Description column followed by two dates, the entry not only posts to QBO, but it also triggers Accruer to spread the entry across the dates in the period. One Booker run produces both the original journal entry and the schedule of monthly recognition entries that follow.
The use case: onboarding existing accruals. A team that has hundreds of prepaid expenses on the balance sheet from before recognition was automated can build a Booker sheet (one row per accrual, with the remaining balance and the remaining service period in the Description) and run Booker once. Each row creates an entry with its own "for the period" tag. The recognition layer immediately starts spreading each one through the end of its period. What would have been hundreds of manual journal entries plus hundreds of manual monthly recognition entries becomes one Booker run plus automatic ongoing recognition.
The same method works for any new transaction with a service period. Monthly bill imports where each row's memo includes the service period. Annual insurance premiums that recognize over twelve months. Software subscriptions billed annually but recognized monthly. The data-flow layer and the recognition layer combine because both read the same Description column.
The decision is usually obvious once you frame it. There are three rough buckets:
Use manual when the entry is a one-off correction, a quarterly tax adjustment a CPA hands you on a memo, or any case where the entry is not going to happen again. The overhead of building automation for a single entry is not worth it. The QBO interface exists for exactly this work.
Use native recurring when the entry is genuinely identical every period. Same accounts, same amounts, same descriptions. Software subscription posted as a journal entry on the same date for the same dollar amount every month. Fixed amortization schedules where the amounts will not change. The native feature handles these cleanly.
Use automated when amounts change, when the entry depends on data from another system, when the work happens in batches (more than five or so entries at a time), or when the same template will run every month with different inputs. This is the largest bucket by far. Payroll allocations. Revenue allocations. Intercompany entries. Subscription and processor accruals. Any close-cycle entry that someone currently builds in a workpaper and types into QBO.
Most teams need all three. The mistake is to use the wrong one for the work: typing a payroll allocation by hand every month because that is how it was always done, or building a recurring template for an entry whose amounts will never actually be the same twice. Knowing which tool fits which work is the operator skill.
Invoicing a customer via journal entry strips out the AR aging, customer-facing detail, and downstream automation that an Invoice transaction provides. Same for paying a vendor via journal entry instead of a Bill or Expense. Journal entries are the catch-all for what does not fit a built-in type, not a substitute for the types themselves.
The native recurring feature is fine when amounts genuinely never change. The moment they do, you spend more time editing each occurrence than you would have spent building the right template once. If amounts depend on monthly data, skip the native recurring feature and use an automated workflow with formula-driven amounts from a raw data tab.
A journal-entry tab that references =Raw!C7 breaks the moment the raw data changes shape: a new row inserted at the top, a hidden subtotal, a column reordered. Use VLOOKUP, INDEX-MATCH, or SUMIFS keyed off labels and dates so formulas find the right cells by content, not by position.
The row is gone from the sheet, but QBO still has the entry. The official way to remove a posted entry: write "delete" in each amount cell, keep the Entry Label and date matching the original, and run again. Works only on Create-and-Update workflows.
The continuous-workbook method only works if the team treats the sheet as the place where journal-entry work lives, not as a one-time import file that gets archived. Old months stay in the workbook (with Hold flags). New months go on top. The historical record matters because it is how the team understands and audits what was posted, and when.
Automate the journal entries
The same Google Sheet, every month, every journal-entry type. If the same templates are being rebuilt or retyped every close, the work is ready for automation. Booker Lite posts journal entries to QuickBooks Online from Google Sheets: formula-driven amounts, the Entry Label sync gate, the continuous-workbook pattern, and the "for the period" integration that hands off to the recognition layer automatically.
Booker also comes in an Unlimited tier covering every QBO transaction type, with the Editor workflow for bulk-editing existing transactions in QBO from a sheet.
QuickBooks Online Advanced has a built-in journal entry import (Gear → Import Data); the lower tiers (Simple Start, Essentials, and Plus) do not. Even on Advanced it is one-way (import only, no update or delete), limited in column support, and does not handle the formula-driven, batched, continuous-workbook patterns most teams need. It works for a one-time historical import. It does not work as an ongoing monthly workflow.
Yes, by populating the Name field on the line. The Name field accepts customers, vendors, and employees. If the account on that line is a receivable or payable, Name is required since QBO needs to know which sub-ledger the activity belongs to. For other account types, Name is optional and primarily affects how the entry appears in name-grouped reports.
No. QBO journal entries do not support sales tax (which is calculated automatically on customer-facing transactions) or inventory items (which require the inventory tracking system). If you need to record sales tax, use an Invoice or Sales Receipt. If you need to adjust inventory, use an Inventory Qty Adjustment (+ New → Inventory Qty Adjustment), available on QBO Plus and Advanced. Journal entries are for GL-level postings only.
QBO has a Reverse function inside an existing journal entry: open the entry, click the More button at the bottom, choose Reverse. QBO creates a new journal entry on the first day of the following month with the debits and credits swapped. The function is fine for one-off reversals. For period-spreading work that needs an entry reversed and then recognized monthly across a service window, the recognition layer (Accruer with the "for the period" tag) is a more complete solution because it generates both the reversal and the monthly recognition entries together.
QBO respects the close date on the company file: entries dated before the close date cannot be posted without explicit override authority. Automated workflows respect this constraint too, using an Effective Close Date that is the later of the QBO close date and the workflow's own close date. If you try to post to a locked period, the entry does not go through; the workflow may either hold the row or post the entry to the first open period, depending on configuration. The recognition layer handles locked periods differently: it catches up in the first open period with a "Catches up & recognizes" entry.
Google Sheets handles concurrent editing natively. The tool syncs on click or on schedule, not in real time, so the question is what the sheet contains at the moment of sync. Standard practice: use Hold values during edits-in-progress to prevent partial syncs, and have a clear convention for who runs the sync when. For larger teams, separate sheets per workflow with clear ownership beats one big shared sheet.
Read these next:
Jonah Rice
Jonah is a CPA and "the guy who does demos" at FinOptimal. Before joining the team he was a customer, using FinOptimal's apps to automate his work at User Interviews, where he climbed from Accounting Manager to Controller. Prior to User Interviews, Jonah held various accounting roles, including kicking off his career in Audit at PwC.
