Closing the Books in 3 Days: How Rillet Customers Compress Month-End

Only 18 percent of finance teams close their books in 3 days or less (source: Ledge 2025 benchmarking study). The median sits at 6.4 calendar days across 2,300 organizations, and teams running manual processes routinely take 10 to 12 (source: APQC). Rillet customers including Postscript, a company with over $100M in ARR, close in 3 days. This piece explains what actually drives that compression, the configuration choices behind it, and, because no vendor will tell you this part, when a 3-day close is the wrong target.

Why the 12-Day Close is the New Bottleneck

The math is unforgiving. A 10-to-12-day close means your CFO makes decisions on numbers that are two weeks stale by the time they arrive, your board deck is built on preliminary figures, and your accounting team spends roughly half of every month producing the past instead of informing the future. One 2025 analysis found finance teams spend a cumulative 72 business days per year on reconciliations and reporting (source: Houseblend close-cycle research, February 2026).

The bottleneck is structural, not personal. Cash reconciliation alone consumes 20 to 50 hours per month for many teams, 94 percent of finance teams still run close activities in Excel, and half of those teams name Excel as the primary reason the close runs slow (source: Ledge 2025). The work scales with transaction volume, so growth makes it worse: the Series B company that closed in 6 days at $10M ARR closes in 12 at $50M unless the process changes structurally.

The Automation Patterns Rillet Ships Out of the Box

Rillet is an AI-native ERP whose architecture starts with native integrations pushing structured data into the general ledger in real time, with AI applied on top (source: Rillet Series B announcement, August 2025). The close-relevant capabilities:

Continuous transaction coding. Data from billing, banking, AP, expense, and payroll systems flows in as structured records and generates journal entries with supporting schedules as transactions occur, not in a month-end batch.
Automated AI reconciliations. Bank and account reconciliations run continuously against the live ledger, so discrepancies surface mid-month when they are easy to fix, not on day 4 of close when everything is urgent.
Automated revenue recognition. Flat rate, usage-based, and milestone pricing models post accurate revenue recognition to the GL automatically, with ASC 606 allocations handled in-platform (source: rillet.com product documentation).
Built-in close checklist. Close tasks, owners, and status live in the platform rather than a shared spreadsheet, which removes the 'is this the latest version' tax that eats a day of most closes.
Flux analysis in clicks. Draft variance commentary generates from the live ledger, turning the most time-consuming analytical task of close into a review exercise.

The Configuration Choices that Drive the Speedup

The platform capability is necessary but not sufficient. In our implementation work, three configuration decisions separate teams that hit 3 to 5 days from teams that bought the same software and still close in 9:

Integration completeness before go-live. Every system feeding the GL through a native integration (billing, banking, AP, expense, payroll) removes a manual import from the close path. Every system left on CSV export keeps one in. The close is only as continuous as the least-connected data source.
Mid-month reconciliation cadence. Continuous close is a process decision, not just a feature. Teams that review AI-proposed reconciliations weekly enter close with exceptions already resolved. Teams that ignore the queue until month-end have simply moved the batch work into a nicer interface.
Revenue model configured to the contract reality. Usage-based and multi-element arrangements need their metering and allocation logic set up correctly once, during implementation. Get it right and rev rec disappears from the close calendar. Get it approximately right and it becomes the recurring day-3 firefight.

Where Automation Hits its Limits

A 3-day close is not a zero-judgment close. The tasks that stay human, on Rillet or any platform:

Novel revenue recognition decisions: new contract structures, multi-element allocation judgments, and standalone selling price estimation.
Materiality calls and accounting policy interpretation. The system assembles the analysis; the controller owns the decision.
One-time transactions: M&A entries, impairments, restructuring accruals. Pattern-matching automation is weakest exactly where patterns do not exist.
Board-ready narrative. AI-drafted flux commentary is a strong first draft. It is not the version that goes to the audit committee.

The honest framing: automation compresses the mechanical 70 to 80 percent of close hours. The judgment layer remains, which is why a 3-day close still requires a controller, just one who spends those 3 days reviewing exceptions instead of keying reconciliations.

Postscript's 3-Day Close: What the Public Record Shows

Postscript, an SMS marketing platform with over $100M in ARR and global operations, closes its books in 3 days using Rillet (source: Rillet Series B announcement, August 6, 2025). Windsurf, one of the fastest-scaling companies in recent memory, runs its entire finance operation with a team of two people on the platform (same source). Rillet also reports customers implementing in as fast as 4 weeks against the 9-to-12-month timelines typical of traditional ERP migrations.

Rillet has not published a step-by-step teardown of Postscript's configuration, so we will not invent one. What the outcome tells you is still useful: a 3-day close at $100M+ ARR with global operations is only mechanically possible when the three configuration conditions above hold. High-volume transaction coding, reconciliation, and revenue recognition must be running continuously, because no team reviews a month of $100M-scale activity from a standing start in 3 days. The case is evidence that the continuous-close architecture works at meaningful scale, not just in demos.

The 30-Day Acceleration Plan for Your Team

Whether or not you change platforms, this is the sequence we use to compress close cycles. It works on Rillet fastest, but the discipline transfers:

Days 1 to 5: Map the current close. Every task, owner, duration, and dependency. Most teams discover 2 to 3 days of their close is waiting, not working: waiting on a report from another team, a statement from a bank, a spreadsheet from whoever owns commissions.
Days 6 to 15: Kill the waiting. Connect the data sources that cause the waits. Move cutoff-dependent tasks earlier. Shift reconciliations from month-end batch to weekly cadence. This step alone typically recovers 2 to 4 days before any AI is involved.
Days 16 to 25: Automate the top three time sinks. For most teams: bank reconciliation, transaction coding, and flux prep. Run automation in review mode alongside the manual process for one cycle to build trust in the output.
Days 26 to 30: Reset the calendar. Publish a new close calendar with the compressed timeline, explicit owners, and a definition of done per task. What gets scheduled gets closed.

When Closing in 3 Days is the Wrong Target

No vendor writes this section, so we will. A 3-day close is the wrong goal when:

Your close is fast but wrong. If post-close adjustments are routine, fix accuracy before speed. A 6-day close that holds up beats a 3-day close that gets restated.
You are mid-audit or pre-IPO with new controls landing. Compressing the calendar while SOX controls are being designed multiplies risk. Stabilize controls first, then compress.
Your operating complexity does not fit the platform. Heavy inventory, manufacturing, or deep multi-entity structures are where full ERPs like Oracle NetSuite remain the right architecture, and where chasing an AI-native close target means fighting your own operating model. This is a fit-by-stage decision, not a ranking of platforms.
The team is the constraint, not the tools. If two people are doing the work of five, a faster calendar just concentrates the same overload into fewer days.

The right question is not 'how fast can we close' but 'what decision is waiting on the close.' If the answer is nothing, a 5-day close with stronger analysis beats a 3-day close with none.

Zanovoy is a Rillet implementation partner and an Oracle NetSuite Alliance Partner. We run close-cycle assessments that tell you honestly whether your bottleneck is the platform, the process, or the team, and whether Rillet fits your operating shape before you commit to a migration.

Frequently Asked Questions

The median is 6.4 calendar days across 2,300 organizations benchmarked by APQC, with top performers under 5 days and the bottom quartile at 10 or more. A 2025 study found only 18 percent of finance teams close in 3 days or less, and small teams running manual processes commonly take 12 to 20 business days.

Rillet's architecture pushes structured data from billing, banking, AP, expense, and payroll into the general ledger continuously, with AI handling transaction coding, reconciliations, and revenue recognition throughout the month. By month-end, close becomes a review-and-approve exercise on work the system has already proposed. Postscript, with over $100M in ARR, closes in 3 days on the platform per Rillet's published announcement.

A continuous close moves close activities from a month-end batch to an ongoing cadence: transactions are coded as they occur, reconciliations run throughout the month, and exceptions surface when they are easy to fix. Month-end then consists of review, judgment items, and reporting rather than data processing.

Novel revenue recognition decisions, materiality calls, accounting policy interpretation, one-time transactions like M&A entries and impairments, and board-ready narrative. Automation compresses the mechanical majority of close hours; the judgment layer stays with the controller.

Not always. Mapping the close, removing waiting time, and moving reconciliations to a weekly cadence typically recovers 2 to 4 days on any platform. Platform change matters most when the bottleneck is architectural: batch imports, manual coding at volume, or revenue recognition that lives in spreadsheets. A close-cycle assessment identifies which case you are in before you commit to a migration.

No. Speed is the wrong target when accuracy is not yet solid, when new audit controls are stabilizing, when operating complexity fits a full ERP better than an AI-native platform, or when the team rather than the process is the constraint. The better question is what decision is waiting on the close.