Glossary

QuickBooks Closing Date

The QuickBooks closing date is the cutoff you set to protect finished periods, after which changing a transaction dated on or before it requires either dismissing a warning or entering a password, depending on how you configured it.

Also called: closing the books, close the books, lock your books, book lock, closing date password

Start a free trial View Pricing

Definition

Intuit describes the feature in one line: after you set a closing date, "You can't change any transactions on or before that date without approval." The word carrying the weight there is approval, not prevention.

Almost everyone reads a closing date as a wall. It is a gate. QuickBooks Online offers two settings behind it, and neither one blocks the edit outright. With the warning-only option, "Users see a warning but can still make changes." With the stronger option, "Users must enter a password to make changes. This is for better security." One is a speed bump and the other is a lock with a key that several people in the building may hold.

That is a defensible design, because real businesses do sometimes have to touch a closed month. It is also why a closing date is a control rather than a guarantee, and why the third piece of the feature matters more than most people realise: QuickBooks keeps a record of what got through. Intuit is explicit that "You can use an Exceptions to Closing Date report to see any changes made after you close your books."

So the honest description of a closing date is a three-part control. It marks a boundary, it makes crossing the boundary deliberate, and it logs the crossings. A business that treats it as the first part only, and never runs the third, has the appearance of a lock without the evidence that anyone respected it.

Key points

+Intuit: after a closing date is set, "You can't change any transactions on or before that date without approval."
+Warning-only setting: "Users see a warning but can still make changes."
+Password setting: "Users must enter a password to make changes. This is for better security."
+It is a soft lock in the interface. It gates edits, it does not block them.
+Intuit: "You can use an Exceptions to Closing Date report to see any changes made after you close your books."
+Set under Settings, then Account and settings, then Advanced, then the Accounting section.
+Intuit: "Only admins can make these changes" to the closing date and its password.
+Anything writing through the QuickBooks API meets the boundary as a rejection: Intuit publishes developer errors 6200 and 6210, both named Account Period Closed.
+The date on a transaction, not the date it was created, is what the closing date is measured against.

A gate, not a wall

The distinction sounds pedantic until you have to answer for a restated month, so it is worth being exact about what QuickBooks does.

Setting a closing date does not make prior transactions read-only. It attaches a condition to editing them. Under the warning-only setting the condition is that someone clicks through a message. Under the password setting the condition is that someone types the closing date password, which is a separate password from the one they signed in with, and which only an admin can set.

The useful mental model is a door with a sign on it rather than a sealed room. The sign is doing real work: it converts an accidental edit into a deliberate one, and most damage to closed periods is accidental. What it cannot do is make the room inaccessible, and no configuration of this feature makes it so.

This also means the strength of your closing date is a people question, not a software question. If the password is shared, or if it is the same one everyone has always used, the control is a warning with extra steps. If it sits with one person who asks what changed and why, it is a real control. The software is identical in both cases.

The report nobody runs

The Exceptions to Closing Date report is the part of this feature that turns a policy into evidence, and it is the part most businesses have never opened.

Its job is simple: show the changes that were made to transactions on or before the closing date after the books were closed. Intuit describes it as the way "to see any changes made after you close your books". Every crossing of the gate is in there.

The reason to run it is not suspicion. It is that closed-period edits are almost always invisible from anywhere else. A restated month does not announce itself on the profit and loss, because the profit and loss simply reports whatever the transactions now say. If a January invoice changed in April, January reports differently in April than it did in February, and nothing in the ordinary reporting stack tells you a change happened rather than a number being different from your memory of it.

A sensible cadence is to run the report at each close for the period you just closed and the one before it. Two minutes, and it either shows nothing or it shows you the thing you would otherwise learn from an auditor.

What the closing date is actually measured against

A closing date compares itself to the date on the transaction, not to the date somebody created or edited it. This is the single most common source of surprise, and it cuts both ways.

A transaction you enter today, dated last March, lands inside a closed period and triggers the gate, even though nothing about it existed when March was closed. A transaction you edit today, dated today, does not trigger anything, even if the edit is far more consequential.

That is why the closing date interacts so directly with anything that back-dates. Documents that carry an original date rather than today are the ones that reach backwards: an amendment to an old document, a correction posted to the period it belongs to, or an automated feed configured to date records by when the underlying activity happened rather than by when it synced.

If you have a feed of transactions arriving from another system, the question worth asking is not whether it respects your closing date. It is which date it stamps on what it writes, because that is the input the closing date judges.

Over the API the soft lock is not soft

Everything above describes a person working in the QuickBooks interface. Software writing into QuickBooks meets a different version of the same boundary, and the difference is worth understanding before you assume an integration behaves like a user.

The override that makes the closing date soft is a password prompt, and a password prompt needs somebody to answer it. An automated write has nobody. So the flexibility that exists for a human at a keyboard is not available to a program acting on your behalf, and the practical result is a refusal rather than a warning.

Intuit publishes developer-support articles for two error codes on this, 6200 and 6210, both under the name Account Period Closed. The existence of dedicated error codes is itself the answer to whether the API enforces the boundary: it does, and it tells the caller so in terms specific to a closed accounting period.

The operational consequence is one you should design for rather than discover. If a correction needs to land in a closed period, that is work for a person in QuickBooks with the closing date password, not something to route through an integration and hope. And if an integration reports that a write failed for a closed period, that is the system working, not breaking.

Choosing the date, and what happens on the first of the month

The mechanics of setting one are quick. Open Settings, then Account and settings, then the Advanced tab, and the closing date lives in the Accounting section. Intuit notes the access constraint: "Only admins can make these changes."

The judgment call is which date to use, and there is a real tradeoff. Setting the closing date to the last day of a period you have genuinely finished protects work that is done. Setting it further back, out of caution, leaves recent months editable by anyone, which is precisely the window where hurried corrections happen.

The common failure is not choosing badly. It is choosing once. A closing date set to last December and never touched has been protecting nothing for months, while still appearing on the settings page as evidence of a control. Moving it forward is part of closing a period, in the same way that filing is, and it takes about the same amount of time as reading this paragraph.

When a period may legitimately be reopened is a policy question for your accountant rather than a software one, and the answer differs depending on what has already been filed against those numbers.

Where this meets a Stripe sync

Acodei does not read your QuickBooks closing date, and nothing in its documentation describes closing-date awareness. What its documentation does describe is the thing that decides whether a synced record lands in a closed period at all: the date it carries.

Several documented settings change that date rather than the amount. Acodei documents invoice-date options that can date a QuickBooks invoice on the Stripe supply date, on the due date, or on Stripe's effective_at value when present, and a payouts option that dates the QuickBooks deposit on the payout creation date instead of the arrival date, whose documented reason to exist is month-end cut-off. Those choices are exactly what determine which side of your closing date a record falls on.

One other documented setting is aimed at closed periods directly. Acodei documents a Create Credit Memo on Void toggle that uses a same-day credit memo rather than voiding the QuickBooks invoice, with the stated purpose of protecting closed periods while invoices are voided in Stripe. That toggle exists because of the asymmetry described above: a void is an edit to a document that already carries its original date, and a credit memo is a new document that carries today's.

All of these are advanced settings rather than self-serve options, so enabling any of them means asking support.

Want to see this on your own Stripe data?

Start a free trial

Frequently asked questions

What does the QuickBooks closing date actually do?

It marks a cutoff after which changing a transaction dated on or before it requires approval. Intuit puts it as "You can't change any transactions on or before that date without approval." Depending on your setting, approval means dismissing a warning or entering the closing date password.

Does a closing date stop transactions from being changed?

No, and this is the most common misunderstanding about it. With the warning-only setting, "Users see a warning but can still make changes." With the password setting, "Users must enter a password to make changes." Neither option makes a closed period read-only.

How do I see what changed in a closed period?

Run the Exceptions to Closing Date report. Intuit describes it as a way "to see any changes made after you close your books", and it is the only routine place a closed-period edit shows up as an event rather than as a number that quietly differs from what you remember.

Where do I set the closing date in QuickBooks Online?

Open Settings, then Account and settings, then the Advanced tab, and find the closing date in the Accounting section. Access is restricted: Intuit states that "Only admins can make these changes" to the closing date and its password.

Can an integration write into a closed period?

It should expect to be refused. The override that makes the lock soft is a password prompt, and automated writes have nobody to answer it. Intuit publishes developer errors 6200 and 6210, both named Account Period Closed, so a rejection of this kind is the boundary working as intended.

Is the closing date compared to the transaction date or the entry date?

The transaction date. A record entered today but dated inside a closed month triggers the gate, while an edit made today to a transaction dated today does not. That is why back-dated records, and any feed that dates records by when the activity happened, are where closed periods get touched.

Should I move the closing date forward every month?

Moving it as part of each close is what keeps it doing work. A closing date left on a date months in the past protects nothing recent while still appearing on the settings page as though a control is in place. When a closed period may be reopened is a question for your accountant.

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.”

RyanOwner at Indie Music Academy