Required means required
A task whose evidence setting is Required cannot be submitted without at least one clean attachment or a recorded link. The application says so at the point of submission rather than accepting it and failing an audit later.
Accounting Close Checklist
The close, as a system of record instead of a shared file.
Every task, every sign-off, every piece of evidence, and every change — with the controls enforced by the software rather than described in a policy nobody re-reads.
Watch
See the close checklist at work.
A walkthrough of the application itself — watch it here, then bring your questions to the call.
Player not loading? Watch the video on YouTube.
The close, period by period
An accounting period is created, released, opened, and closed. Releasing generates that period's tasks from your memorized templates — until then the period exists but has no work in it. Closing is refused while any required task is short of approved or not applicable.
Reopening a closed period is permitted and never quiet. It asks for a reason, counts the reopen on the period record, and writes the whole of it to the audit trail. A period reopened three times is telling you something about the close calendar, and now you can see it.
Dates that survive a bad month
Due dates are business days after period end, not fixed calendar dates. A date that lands on a weekend or a company non-working day rolls forward. A template written once resolves correctly in every period, including years whose periods are not months at all — 4-4-5, 4-5-4, 5-4-4, and thirteen-period calendars are all supported, with audit adjustment periods.
Sign-off the software will not let you skip
Three review levels: self-certify, prepare-and-review, and prepare-review-approve. A person cannot be assigned as both preparer and reviewer of the same task — the application refuses the assignment rather than allowing the self-review, so the conflict never exists to be caught.
Rejection is part of the process rather than a failure of it. A rejection carries a reason, the task returns to the preparer, and the count of reworks is kept. A task reworked every period has a definition problem, not a person problem, and the performance analysis says so.
A sign-off is a historical fact, not a current permission. Removing a role from somebody never strips their name from work they already signed, and a terminated user keeps their signature on every record they touched.
Evidence
The workpaper lives on the task it supports.
Not in an email thread, and not in a folder somebody has to remember the name of.
Five sections, in reading order
Procedures, workpaper, GAAP reference, IFRS reference, and other. An empty workpaper section on a reconciliation is itself worth seeing, so every section stands whether or not anything is filed in it.
Templates carry standing references only
Procedures and technical references carry forward onto the memorized task. Workpapers deliberately do not — copying last month's reconciliation onto a template would satisfy this month's evidence rule without anybody doing the work.
Analysis
Two questions, and they are not the same one.
Trial Balance Review — should I believe these numbers?
Every trial balance imported for an entity, lined up in period order, with the movement between each pair of periods beside the balance. Balances are shown at their natural sign, so a payable reads as a positive credit balance — and anything negative is abnormal by definition.
A movement is only raised when it clears a percentage of the prior balance and a currency floor, together. Either test alone produces a page of noise: every small account moves by large percentages, and every large account moves by large amounts.
- An account carrying a balance on the side opposite its statement group
- A balance that cleared entirely — settled, reclassified, or missing from the file
- A movement more than twice the largest that account has ever had, judged against its own history
- An account that appeared for the first time, or has not moved at all in three periods
- An account with no statement group, silently excluded from every ratio
Nothing here is called an error. A 300% jump in professional fees in the month of an acquisition is correct and still worth seeing.
Financial Ratios — what do they say?
Standard metrics across liquidity, leverage, efficiency, and profitability, computed from the imported trial balance and stored with the definition version that produced them, so a figure stays reproducible after the definition changes. Market value ratios are defined too, and are hidden entirely rather than shown empty when no share price or share count is available — a trial balance does not carry either.
Each is read against the prior period, a generic benchmark range, and the range for the industry the entity is actually in. The source of those industry ranges is printed beside them on screen and in the report — a benchmark whose provenance is not stated is a number you cannot weigh.
Close performance, alongside both
How the close actually went, compared against the same entity's own history: what went well, which tasks and people the close keeps stalling on, and reviewer load, which is a capacity finding rather than a performance one.
It also tests whether the dates are realistic. A task missed by nearly everybody in nearly every period is a date problem, and the report says so — along with how many business days the date would have to move — instead of reporting the same person late twelve times.
Getting data in and out
Your column headings, not ours.
Every import is the same three steps: choose the file, map its own headings to the application's fields, then read a row-by-row preview before anything is committed.
| Record | Import | Export | Notes |
|---|---|---|---|
| Trial balance | Yes | — | A new import supersedes the standing one; both stay on file. A correction merges over it. |
| Entities | Yes | Yes | Includes the industry field the benchmarks read. |
| Chart of accounts | Yes | Yes | Statement group drives every ratio computed from the account. |
| Categories and sub-categories | Yes | Yes | Two separate imports, because they are two separate records. |
| Segments and segment values | Yes | Yes | Departments, locations, classes, and any custom dimension. Locations carry the subsidiary they belong to. Exported one file per segment. |
| Tasks and memorized tasks | Yes | Yes | Your existing close calendar becomes the first template. |
| Non-working days | Yes | Yes | Business-day due dates skip them and roll forward. |
| Accounting periods | — | Yes | Generated from the fiscal calendar wizard. |
| Users | Yes | Yes | Matched to roles the company already holds. The export carries no password material of any kind. |
| Roles and permissions | No, deliberately | Yes | A spreadsheet full of permissions is how approval rights get granted by accident. |
Access, and the record of it
Roles decide what a person may do; data access decides what they may see — the entities they are assigned to, and the segment values within them. A person restricted to two locations sees two locations' worth of tasks, imports, and figures everywhere in the application, not only on one screen.
A location belongs to one subsidiary, so a task cannot be coded to a location in another legal entity. A location is a physical place and a place is owned by one company; departments and classes are deliberately not scoped that way, because Finance means the same thing in every subsidiary of a group and should be defined once. A location that groups others — a region — names no subsidiary, because a region may legitimately span several.
Everyone can read their own limits. A person who cannot see the limits on their access has no way to tell a missing task from a limit nobody told them about.
Creating and assigning roles is one permission. Changing which permissions a role holds is a second one, held separately — because the ability to add a permission to a role is the ability to grant every permission in the application.
One database per client, and the solutions you subscribe to inside it. BOLD Accounting Solutions runs more than one product on the same platform, and your company holds one database rather than one per product. Adding a solution installs nothing and moves no data — its screens and permissions simply become available. Ending one deletes nothing: your records stay where they are, and come back if you take it up again. Your accounting periods, entities, segments and chart of accounts are shared across the solutions you hold rather than set up twice.
Every permission in the application records which solution it belongs to, or records that it belongs to all of them — signing in, roles, the audit trail and support are not any one product's. So the roles screen offers you the permissions of the products you have, and names the rest rather than leaving a gap where a button used to be. A permission belonging to a product you have ended stops working rather than merely disappearing from a list — and stops working without being removed from the role, so taking the product up again restores every role exactly as it was, with nothing rebuilt.
One subscription per solution, and one figure a month. Each solution has its own term, its own seat count and its own payment terms, and the Company screen adds them into what you pay a month. Where the terms are the same it is one invoice; where they differ they are invoiced separately, because an invoice with two due dates is one your accounts-payable team cannot process.
Seats are counted per solution, and by what people actually do. Somebody uses a seat in a solution because a role they hold carries one of that solution's permissions — so a preparer working only on the close does not consume a fixed-asset seat, and nobody has to keep a licence list in step with a roles list. There is one list, and it is the one you already maintain.
Everyone gets the instructions for their own job
Each role carries a user guide, shown on the dashboard at sign-in and downloadable as a Word document. The written sections explain what the job is, which screens are yours, and what the role deliberately cannot do — because the most common support question is about a button that is not there.
The permission appendix is generated from the role at the moment the guide is downloaded, so it describes the role as it stands rather than as somebody once wrote it down. Take a permission away and every copy printed after that says so.
A role your team creates starts on the guide of the role it was copied from, and can be adapted into your own file cabinet without touching anybody else's copy.
Questions
Straight answers.
Does this replace my ERP or my general ledger?
No, and it should not. The Accounting Close Checklist manages the close around your ledger: what has to be done, who does it, who reviews it, what evidence supports it, and whether the period can be closed. It reads a trial balance out of your system; it never posts one back. Your ERP stays the book of record.
Does it only work with NetSuite?
It is built for NetSuite users first, because that is where twenty-five years of accounting experience and ten years of NetSuite work meet. But nothing in it is NetSuite-specific: the trial balance arrives as a CSV whose column headings you map to the application's fields, so QuickBooks, Sage Intacct, Dynamics, Xero, or a spreadsheet export all work the same way. Entities can also be configured with no accounting system at all.
How does it enforce segregation of duties?
By refusing the assignment rather than the sign-off. A person cannot be set as both the preparer and the reviewer of the same task, so the conflict is prevented where it is created instead of being caught later. A task set to prepare-review-approve needs two different people to sign after the preparer, and neither can be the preparer.
What counts as evidence, and where does it live?
A file held by the application, or a recorded link to a document kept somewhere else. Either satisfies a required-evidence rule, and the difference is stated on the record: the application can hash and version a document it holds, and it cannot tell you when somebody else changes one it only points at. Evidence is filed against the task it supports, in five sections a reviewer reads in order — procedures, workpaper, GAAP reference, IFRS reference, and other.
What is the trial balance review?
A second tab on the Financial Ratios screen that answers the question that comes before the ratios: whether to believe the numbers at all. It lines up every trial balance imported for an entity in period order, puts the movement between each pair of periods beside the balance, and raises anything worth a question — an account carrying a balance on the wrong side, one that cleared entirely, one that appeared, one that moved more than twice its own largest movement, one that has not moved at all in three periods. Nothing is called an error. Every flag is a question.
Can I get my data out?
Yes, and each export is its own permission by record type: tasks, entities, memorized tasks, the business day calendar, accounting periods, categories, segments, the chart of accounts, users, and roles. The reports generate as Word documents. Roles export with their permissions and are deliberately not importable — permissions arriving from a spreadsheet is how approval rights get granted by accident.
How many people can use it?
As many named user seats as the subscription covers, five by default. A seat is held by an active user; somebody suspended or gone stays on the record without occupying one, and keeps their name on everything they already signed.
Is my company's data separated from anyone else's?
Your company gets its own database. Not a column on a shared table with a filter over it — a separate database, created when you are set up, holding only your close. A connection is opened against it after you sign in and it is the only one that request can reach; nothing in the system takes a company name from the browser, because a request that names its own company is the most common way a shared system leaks. The roles you create belong to you alone — no other customer sees them, can assign them, or is told they exist.
Who can see a period after it is closed?
Whoever the role says, and it is set on the role rather than for the whole company. A preparer reads back the most recent few periods by default; a close manager or an administrator reads every one; an executive reads the fiscal year being worked in, because that is the unit they think in. The picker says how many older periods exist but are not shown, so a short list reads as a permission rather than as missing data. A closed period is read-only for everybody — changing anything in one means reopening it, which is counted and needs a reason.
How are due dates worked out?
From your own business day calendar. A task due on the third business day after period end is resolved against your working week and your non-working days, not against a fixed Monday-to-Friday assumption — a company working Sunday to Thursday is expressed directly. Days come in from a CSV or are entered by hand, and taking one out of use makes it a working day again rather than leaving it half-applied. The same arithmetic runs in the database as on the screen, so a report and a screen cannot give a task two different due dates.
What does the audit trail actually record?
Every change, in the same transaction as the change. If the write is rolled back the entry goes with it, and if the entry cannot be written the change does not happen — so there is no state where the record says something occurred that did not, or stays silent about something that did. Each entry names the person or the API key, their role, the record, the field, and its value before and after. The table refuses updates and deletes outright, including from the application itself. Filter it by date, actor, record, or event and export the result as CSV.
Bring your close calendar to the call.
Thirty minutes with the tasks that always slip is worth more than any demo script.