by Sharai Lavoie | Apr 14, 2026 | Software
The Timing Decision That Determines Whether Your Income Statement Reflects Reality or Assumptions
The Scenario That Creates the Problem
Your engineering team is twelve months into a major SaaS implementation. The contract includes $400,000 in implementation fees covering both standard setup work and platform-specific development that modifies the source code. The go-live date is still three months away.
Your accounting team is recognizing all implementation revenue over time using a cost-to-cost method. Progress looks steady. The income statement looks healthy.
The problem: half of that implementation work is not distinct from the SaaS subscription. That revenue should be sitting on the balance sheet, not flowing through the income statement.
Two Buckets, Two Timelines
Implementation services in a SaaS arrangement fall into two categories. Non-complex services that provide standalone value to the customer are recognized over time as they are delivered. Complex services that modify the platform’s source code are not distinct from the SaaS and must be combined into a single performance obligation.
The timing implications are significant:
Non-complex services (Group A): Revenue begins immediately. As the team completes gap analysis, data conversion, system architecture, and training, the customer is consuming and benefiting from those activities. Recognition follows a measure of progress, typically a cost-to-cost or labor hours method.
Complex services (Group B): Revenue is deferred. Because these activities are inputs to the SaaS itself, their value is not transferred until the product goes live. The implementation fees attributable to Group B sit as deferred revenue on the balance sheet until the go-live date, then amortize over the remaining contract term alongside the SaaS subscription.
The Allocation Challenge
Splitting a single implementation fee between Group A and Group B requires determining the standalone selling price of each set of services. For many software companies, this is the hardest part.
Non-complex services often have observable pricing, such as gap analysis, training, or data migration services, or the services may be available from third-party providers at known rates. Complex services, by contrast, are rarely sold independently. Their value is embedded in the SaaS subscription.
The result: companies frequently need to estimate the standalone selling price using either an adjusted market assessment approach or an expected cost plus margin approach. The methodology must be documented and applied consistently across contracts.
Subcontractor Costs Follow the Same Split
When third-party development partners or subcontractors provide services during the implementation period, their costs must be bifurcated between Group A and Group B activities, and between the pre-go-live and post-go-live periods.
Consider a security monitoring subcontractor that provides services throughout both the development period and the post-go-live operational period. The portion of their costs attributable to the pre-go-live development work is allocated to Group B and deferred. The portion attributable to the post-go-live period is recognized as a cost of revenue alongside the SaaS subscription revenue.
This cost bifurcation ensures that cost recognition matches revenue recognition, a fundamental principle that many software companies overlook when they treat subcontractor invoices as period expenses.
The Materiality Consideration
ASC 606 permits a practical expedient: if a performance obligation is immaterial in the context of the contract, the entity is not required to account for it separately. Some companies use this to simplify the allocation.
For smaller implementation engagements, where the total implementation fee is modest relative to the overall contract value, a company may conclude that the implementation fees are immaterial and defer the entire amount until go-live. This is a defensible position when properly documented, and it simplifies the accounting without materially affecting the financial statements.
The key is documentation. The materiality assessment must consider both quantitative and qualitative factors, and the conclusion must be applied consistently.
Real-World Application
A software company with a proprietary platform signs a five-year SaaS contract with a total implementation value of $6,000. The contract includes both non-complex deliverables and complex source code modifications.
Management evaluates the implementation fees and determines they are immaterial in the context of the overall contract. Rather than splitting the fees between Group A and Group B, the company defers the entire implementation amount until the go-live date, at which point it begins recognition over the remaining contract life.
This approach is simpler, defensible, and produces financial statements that accurately reflect the economic substance of the arrangement. The company documents its materiality assessment and applies the same methodology to similar contracts.
The Bottom Line
Implementation revenue timing is not a single decision. It is a series of interconnected determinations: which services are distinct, what their standalone selling prices are, when the customer receives value, and whether the amounts are material enough to warrant separate treatment.
The companies that get this right build their revenue models contract by contract, with documentation that supports each classification. The companies that get it wrong are building income statements that will eventually need to be corrected.
At Lavoie CPA, we work with software and SaaS companies that need their implementation revenue to reflect how value is actually delivered to customers.
Start the Conversation Today
by Sharai Lavoie | Apr 14, 2026 | Youth Sports Clubs
Your Financial Playbook for Disciplined Growth
A budget should answer one question: are we on track?
Not “how did we do last year.” Not “what did we spend.” Just a clear signal about whether the club is executing its plan or drifting away from it.
For a single-location club, that answer is usually simple enough. The numbers are small, the people are close to the money, and intuition fills the gaps that reporting leaves open.
But the moment a club adds a second location, a travel program, or a summer camp, that simplicity disappears. And what replaces it is not complexity. It is confusion.
Budget vs. Actual reporting is where that confusion either gets resolved or gets buried. Done well, it becomes a halftime adjustment, a structured pause that tells leadership what is working and where to intervene. Done poorly, it becomes a backward-looking exercise that nobody trusts.
The difference is not effort. It is design.
Why budgets break when clubs grow
Most clubs build their first budget the way most small organizations do: someone estimates revenue, estimates expenses, and the difference becomes the plan. It works because the person who built it is also the person spending the money.
Growth breaks that loop.
When a second location opens, someone new is making spending decisions. They may not know how the original budget was built. They may not use the same categories. They may not even define “program expenses” the same way.
This is not a people problem. It is an architecture problem. The chart of accounts that made sense for one location now produces conflicting data across two. The cost categories that were clear when one person managed them become ambiguous when three people interpret them differently.
The result: a budget that technically exists everywhere but means something different in each place.
Why variances lie without context
Even when the structure is consistent, the variances it produces can mislead.
A ten percent overage in equipment spending sounds significant. But if one location budgeted conservatively and another budgeted aggressively, the same percentage tells two different stories. Without context, variances become noise, leadership sees numbers, asks for explanations, and receives narratives constructed after the fact.
Context comes from how the budget was built. When budgets are driven by activity, number of players, teams, camp weeks, tournament entries, every variance traces back to a specific operational reality. The conversation shifts from “why did we overspend” to “what changed, and does our plan still reflect it.”
What a system that works looks like
Moving from broken reporting to reliable reporting requires three structural decisions.
Standardization. Every budget across every location must use the same chart of accounts, the same cost categories, and the same format. This does not mean every budget looks identical. It means every budget speaks the same language. A dollar categorized as “field rental” in one location must mean the same thing in another.
Driver-based construction. Instead of last year’s numbers plus a percentage, budgets should be built from the activities that generate revenue and cost:
- Players per program
- Coaches per team
- Weeks per season
- Tournament entries per age group
When enrollment drops from 120 to 95, the model recalculates every affected line. Leadership does not have to guess the impact. The structure shows it.
A monthly review cadence. A budget built in August and revisited in June is a historical artifact, not a management tool. Fifteen minutes of structured monthly review, where are we off plan, why, and what are we doing about it, prevents hours of year-end explanation.
What changes for leadership
When these decisions are in place, the experience of running a multi-location club shifts.
Board conversations become cleaner. Instead of numbers with caveats, leadership presents consistent comparisons across locations with clear explanations for material variances.
New program launches accelerate. The standardized template absorbs new inputs without breaking. What used to take weeks of spreadsheet work becomes a matter of entering assumptions into a proven model.
Accountability becomes structural. When every location operates on the same playbook, performance comparisons are fair. The structure removes ambiguity, and what remains is operational performance.
And financial surprises decrease, not because the business becomes more predictable, but because the system surfaces deviations early enough to respond. A variance caught in month three is an adjustment. A variance discovered in month eleven is a crisis.
Your first moves this season
- Lock in a single, consistent chart of accounts across all locations. This chart of accounts should be used for both budgeting and accounting purposes.
- Rebuild your master budget using activity drivers, players, teams, weeks, events, instead of flat dollar estimates.
- Load approved budgets into your financial system so actuals flow against them automatically.
- Set a monthly review cadence with location directors.
From reporting to steering
A budget you cannot track against reality is just a guess. When Budget vs. Actual reporting matches how your club actually operates, structured by program, driven by activity, reviewed with discipline, budgeting becomes a tool for clarity, control, and confident growth.
With visibility and budget discipline in place, clubs are ready to build the governance and workflows that support the next phase of expansion.
At Lavoie CPA, we work with growing youth soccer clubs to build financial systems that match the complexity of multi-location operations.
Start the Conversation Today.
by Sharai Lavoie | Apr 6, 2026 | Financial Services, Technology
Most growing companies do not have a finance technology problem. They have a finance technology accumulation problem.
Over time, tools get added to solve specific pain points. An invoicing platform here. An expense management tool there. A reporting layer on top of the ERP. Each tool solved the problem it was purchased for. But collectively, the stack evolved without a unifying architecture, and the result is a set of disconnected systems that create as much manual work as they eliminate.
This is not a failure of technology selection. It is a failure of the technology strategy. Now it’s April, after the intensity of Q1 has passed and before the pressures of mid-year reporting arrive, the right time to assess whether your tech stack is accelerating your finance operations or quietly constraining them.
The Bottleneck Test
There is a straightforward way to determine whether your technology is helping or hindering. Answer three questions honestly.
First: How many times does the same data point get entered manually across your systems? If a vendor invoice requires manual entry in your AP platform, manual coding in your ERP, and manual reconciliation in your bank feed, you have a systems integration gap. Every manual touchpoint is a potential error, a time cost, and a dependency on human availability.
Second: How long does it take to answer an unplanned financial question from leadership? If the CEO asks for a margin breakdown by product line and the answer takes more than a few
hours, the constraint is not the complexity of the question. It is the accessibility of the data. A well-integrated stack should enable the finance team to query, filter, and present financial data without having to build a new spreadsheet each time.
Third: Could your finance team operate at the same quality level with one less person? If the answer is no because of the amount of manual work the current systems require, then your technology is consuming capacity rather than creating it.
Common Patterns of Tech Stack Debt
The ERP was implemented but never optimized. This is the most common pattern in growing companies. The ERP was deployed, core functions were configured, and the team moved forward. But the advanced capabilities, the ones that would automate consolidation, streamline multi-entity reporting, and enable real-time dashboards, were deferred to a “Phase 2” that never happened. The result is a powerful tool operating at a fraction of its potential, with the team filling the gaps manually.
The point solutions never got connected. The company uses Bill.com for payables, Ramp for expense management, Sage Intacct for the general ledger, and Excel for reporting. Each tool works well individually. But when one is not connected to the core general ledger, manual imports are required. The team spends time reconciling across systems instead of analyzing the data within one source of truth..
The reporting layer creates more work than it saves. Some companies add business intelligence tools on top of their ERP, expecting self-service analytics. But without clean, consistent data underneath, the BI layer simply surfaces the same data quality issues in a more visible format. The team then spends time explaining why the dashboard numbers do not match the ERP numbers, which is worse than not having a dashboard at all.
The legacy system that everyone works around. There is often one system in the stack that everyone knows needs to be replaced, but no one wants to tackle it. Maybe it is a payroll system that requires manual journal entries every period. Maybe it is a billing platform that cannot handle the company’s current pricing model. The cost of keeping it is invisible because the team has absorbed it into their routine. The cost of replacing it feels daunting because of the migration effort. But the compounding cost of workarounds grows every month.
How to Run a Meaningful Tech Audit
A useful technology audit is not a vendor evaluation exercise. It is an operational assessment that maps how data actually moves through the organization to the finance function and identifies where that movement creates friction.
Start by mapping the full data lifecycle for your three most critical processes that touch finance: the monthly close, accounts payable, and financial reporting. For each process, document every system involved, every manual step, every data transfer, and every point where a human must intervene to move information from one place to another.
Then categorize each manual intervention. Is it necessary because of a system limitation? Because of a configuration gap that could be resolved? Because of a process design choice that prioritized speed over sustainability? Or because of a knowledge gap where the team does not know the system’s capabilities?
The categorization matters because it determines the solution. System limitations require changes or additions. Configuration gaps require implementation work. Process design issues require workflow redesign. Knowledge gaps require training or documentation. Treating all of them as technology problems leads to expensive solutions that do not address the actual constraint.
The Integration Question
The single most valuable improvement most growing companies can make to their finance tech stack is understanding the full workflow and optimizing the tools they already have.
Integration eliminates the manual handoffs that consume the finance team’s time and create reconciliation burden. When your AP platform writes directly to your general ledger with the correct coding, the team does not need to re-enter or verify the data. When your bank feeds automatically match against expected transactions, the reconciliation process shrinks from hours to minutes. When your reporting pulls directly from the ledger without an intermediate export, the numbers are always current and always consistent.
The companies that get the most from their technology investment are not the ones with the most sophisticated tools. They are the ones whose tools share data cleanly, consistently, and without human intervention.
Making the Assessment Actionable
A tech audit that produces a report but no action is a waste of time. The output should be a prioritized list of changes, ranked by the combination of impact on team capacity and implementation complexity.
Quick wins typically include completing deferred configurations in existing systems, setting up automated bank feeds, and enabling standard integrations between tools that already support them. Medium-term projects often involve redesigning the chart of accounts for multi-entity reporting, implementing approval workflows that eliminate email-based approvals, and building automated close checklists. Longer-term initiatives might include migrating off legacy systems, implementing a BI layer on top of clean data, or re-implementing an ERP that was never fully configured.
The key is sequencing. Start with the changes that free the most team capacity with the least disruption. Use that recovered capacity to tackle the next layer. Each improvement compounds, as it reduces the manual work that slows everything else down.
Technology as Infrastructure
The right way to think about your finance tech stack is not as a set of tools. It is an infrastructure. Just as physical infrastructure can either support or constrain growth, so too can digital infrastructure. And just like physical infrastructure, deferred maintenance compounds into structural risk.
April is the right time for this assessment. Q1 is fresh enough that the team remembers exactly where the pain was. And there is enough runway before mid-year to implement changes that will make a measurable difference.
At Lavoie CPA, we help companies assess their finance technology, identify integration gaps, and build connected systems using platforms like Sage Intacct, Bill.com, and Ramp.
Start the Conversation Today.
by Sharai Lavoie | Apr 6, 2026 | Financial Services, Outsourcing
There is a particular kind of Q1 that leadership teams celebrate and finance teams quietly dread.
The books closed on time. Every report was delivered. Board materials were polished and accurate. From the outside, the quarter was a success. From the inside, the finance team knows exactly what it cost: late nights during the last week of the month, manual workarounds that should have been automated two years ago, and a closing process that depended on three people being available simultaneously with no margin for error.
This is what operational heroics look like in finance. The work gets done, but the method is neither repeatable, scalable, nor sustainable.
The Heroics Trap
Heroics create a dangerous feedback loop. When the team delivers results through extraordinary effort, leadership has no reason to question the underlying structure. The outcome is the same whether it was produced by a well-designed system or by a controller working until midnight. From a results perspective, both look identical.
The difference only becomes visible under two conditions: when volume increases, and the team cannot absorb the additional load, or when a key person becomes unavailable and the process breaks.
By the time either condition materializes, the cost of fixing the underlying structure is significantly higher than it would have been during a period of relative stability. The organization has optimized for output without investing in the infrastructure that sustains it.
Five Warning Signs That Heroics Are Masking Structural Risk
The close takes longer every quarter. Not dramatically, but consistently. What took four days now takes five. What took five now takes six. Each incremental day adds complexity that existing processes cannot absorb without more time or effort.
Key processes depend on specific people. If the team cannot close the books, produce a board deck, or reconcile intercompany transactions when one particular person is out, the organization has a knowledge concentration problem. This is not a talent issue. It is a design issue.
The team avoids taking time off during predictable periods. When finance team members consistently decline vacation during the last week of the month, during quarter-end, or during planning season, it signals that the processes cannot function without their direct involvement. The constraint is not workload. It is a structural dependency.
Workarounds have become permanent. Every finance team has workarounds. The problem arises when temporary solutions become permanent fixtures. A manual journal entry that was supposed to be automated after the system migration. A reconciliation spreadsheet that was supposed to be replaced by a system integration. A reporting template that was supposed to be rebuilt in the new platform. When workarounds persist for more than two quarters, they are no longer workarounds. They are the process.
The team is reactive to leadership requests. If producing an ad hoc analysis for the CEO takes more than a day, or if answering a board member’s question requires the team to pull data from multiple disconnected sources, the finance function is optimized for routine output rather than strategic responsiveness. This is a structural limitation, not a performance one.
What Sustainable Looks Like
Sustainable finance operations share a set of common characteristics that distinguish them from heroics-dependent models.
Processes are documented and transferable. Any qualified team member can execute the close, produce a report, or run a reconciliation using documented procedures. The knowledge lives in the system, not in any individual.
Systems are connected, and data flows automatically. Manual data transfers between tools are the exception, not the rule. When a transaction posts in the ERP, it flows through to reporting, consolidation, and analysis without manual intervention.
Capacity planning is built into the operating model. The team knows its throughput limits and has a clear plan for how additional volume, entities, or complexity will be absorbed. Growth does not create an emergency. It triggers a predefined scaling response.
Close timelines are stable or improving. A well-structured finance function closes faster as it matures, not slower. If the timeline is extending, the root cause is almost always technical debt accumulating faster than the team can address it.
Making the Shift
The transition from heroics to systems does not require a massive transformation initiative. It requires a commitment to identifying the highest-impact structural gaps and closing them methodically.
Begin with the close process. Document every step. Identify which steps require manual effort and why. Determine whether the root cause is a missing integration, an undocumented process, or a knowledge gap. Assign ownership for resolving each gap and set a timeline.
Then move to reporting. Audit how data moves from source systems to the reports that leadership consumes. Every manual step in that chain is a potential point of failure and a candidate for automation.
Finally, examine the team’s time allocation. If more than half of the finance team’s hours are spent on execution and processing rather than analysis and strategy, the function is structurally underinvested. The solution is not hiring more people. It is removing the structural barriers that prevent the existing team from operating at the level the business needs.
The Real Metric
The measure of a strong finance function is not whether it delivered this quarter. It is whether it can deliver the next four quarters at the same quality without increasing headcount or extending timelines.
If the answer depends on the same people working the same hours with the same workarounds, the function is running on heroics. And heroics, by definition, are not a strategy.
At Lavoie CPA, we help leadership teams build finance operations that deliver consistent results through structure, not stamina.
Start the Conversation Today.
by Sharai Lavoie | Apr 6, 2026 | Financial Services
Every finance team has a version of the same story after Q1.
The books closed. The deadlines were met. Reports were delivered. From the outside, everything worked. Leadership saw results and moved on.
But inside the finance department, the reality was different. Reconciliations were held together by last-minute effort. Key processes depended on one person who happened to be available. Workarounds became workflows. And the team quietly absorbed pressure that no system was designed to handle.
That gap between what leadership sees and what the finance team actually experiences is technical debt in financial operations.
What Does Technical Debt in Financial Operations Really Mean
The term “technical debt” is well understood in software engineering. It describes shortcuts taken during development that create long-term maintenance burdens. Technical debt in financial operations works the same way.
It accumulates when financial operations grow through improvisation rather than design. When a company adds entities, hires team members, expands revenue streams, or layers on new tools without rethinking how data flows, approvals move, and decisions get made, the result is a finance function that technically works but structurally strains under any increase in volume or complexity.
Technical debt does not announce itself with a single failure. It reveals itself gradually through patterns that become familiar: month-end closes that take longer each quarter, reconciliations that require manual intervention every cycle, reporting that depends on tribal knowledge rather than documented processes, and a growing sense among the team that they are managing despite the system rather than because of it.
Why Q1 Is the Stress Test Most Companies Ignore
The first quarter of any year concentrates pressure in a way that few other periods do. Year-end close overlaps with annual planning. Tax preparation runs parallel to board reporting. Forecasts built in January collide with operational realities by March.
For companies carrying technical debt in their financial operations, Q1 does not just test the finance team; it tests the entire organization. It exposes the structural limits of the function’s design.
Consider what happens during a typical Q1 under technical debt. The team closes the books, but the process requires a senior team member to manually reconcile data across systems because integrations were never fully configured. Reports are delivered on time, but the numbers pass through three spreadsheets before reaching their final format. Cash flow visibility exists, but only because one person runs a manual pull every Monday morning.
Each of these individually seems manageable. Collectively, they represent a finance function operating at capacity with no margin for growth, no resilience against disruption, and no ability to absorb additional complexity.
The Three Layers of Technical Debt in Financial Operations
Technical debt in financial operations typically accumulates across three layers, each compounding the others.
Systems debt is the most visible. It shows up as disconnected tools, redundant data entry, and integration gaps. A company might run Sage Intacct for accounting, but still rely on Excel for consolidation because the multi-entity configuration was never completed. Or it uses Bill.com for payables, but tracks approvals in email because the workflow was never fully mapped. Systems debt does not mean the tools are wrong. It means the tools were implemented to solve an immediate problem rather than designed to support how the business actually operates at scale.
Process debt is harder to see but often more damaging. It lives in the undocumented steps between systems. The manual journal entries that happen every month because a recurring transaction was never automated. The reconciliation requires someone to compare two exports side by side because the chart of accounts was not standardized across entities. The close checklist that exists in someone’s head rather than in a shared workflow. Process debt turns the finance team into a bottleneck without anyone realizing it because the work still gets done.
Knowledge debt is the most dangerous because it creates single points of failure. When critical processes depend on one person’s memory, experience, or availability, the organization has traded scalability for dependency. Knowledge debt becomes visible only when that person is unavailable, whether through illness, vacation, promotion, or departure. By then, the cost of rebuilding what was never documented or transferred is significantly higher than it would have been to formalize it in the first place.
Measuring the Cost
Technical debt in financial operations is expensive, but not in ways that appear on a standard financial statement. The cost shows up in opportunity: what the finance team cannot do because it is consumed by what it must do.
A team spending 40% of its time on manual reconciliations is not analyzing margin performance, modeling scenarios, or supporting strategic planning. A controller who spends the last week of every month in close mode is not advising on capital allocation or identifying cost-optimization opportunities.
The measurement is not complicated. Map the finance team’s time across three categories: execution work that could be automated or systematized, analysis work that directly informs decisions, and strategic work that shapes the company’s direction. In organizations carrying significant technical debt, execution work often consumes seventy to eighty percent of the team’s capacity. In well-structured operations, that number drops to thirty or forty percent, freeing the team to operate as a strategic function rather than a processing center.
From Surviving to Sustaining
Addressing technical debt in financial operations does not require replacing every system or redesigning every process at once. It requires an honest assessment of where the finance function is structurally vulnerable and a disciplined plan to close those gaps in order of impact.
Start with the close process. If the month-end close requires more than five business days, the drivers are almost always technical debt. Map every step, identify where manual intervention is required, and determine whether the root cause is a systems gap, a process gap, or a knowledge gap. Each has a different solution, but all three share the same symptom: elapsed time that cannot be compressed without adding people.
Move to reporting and visibility. If leadership cannot access reliable financial data without requesting it from the finance team, the organization is operating with a visibility deficit that slows decision-making. Real-time dashboards, automated report distribution, and self-service analytics are not technology luxuries. They are infrastructure investments that reduce dependency on the finance team for information and increase its capacity for analysis.
Then, examine the technology layer. Not whether the tools are modern, but whether they are connected. A best-in-class ERP paired with disconnected point solutions creates more technical debt than a simpler stack that cleanly shares data. The question is not “Do we have the right tools?” It is “Do our tools talk to each other in a way that eliminates manual handoffs?”
The Leadership Conversation
Technical debt in financial operations is ultimately a leadership topic, not a technology one. It determines how quickly the organization can grow, how accurately it can forecast, and how confidently it can make capital-allocation decisions.
The companies that scale most effectively are not the ones that invest the most in finance technology. They are the ones who invest intentionally, connecting systems to processes and processes to people in a way that builds capacity rather than consumes it.
Q1 is over. The question is not whether your finance team survived. The question is whether the way they survived is sustainable for the next four quarters.
If the answer requires honesty, that honesty is the first step toward building something stronger.
At Lavoie CPA, we work with growing companies to identify technical debt in financial operations, design scalable finance operations, and build systems that support growth without burning out the team.
Start the Conversation Today.
