Revenue Intelligence Blog

7 AI Agents Every SaaS Revenue Team Should Automate

 

The Real Question Isn't "Should We Use AI?" — It's "Which Tasks Actually Need a Human?"

Every SaaS finance team we talk to has some version of the same daily routine: check AR aging, decide who to chase, send dunning emails, check which subscriptions need invoicing, check for compliance deadlines, look at the renewal pipeline, scan for unusual revenue entries. None of this requires deep judgment most days — it requires doing it consistently, every day, without fail.

That's precisely the kind of work AI agents should handle — not by replacing financial judgment, but by making sure the repetitive groundwork never gets skipped.

The 7 Tasks Worth Automating

1. Collections. Dunning sequences, promise-to-pay tracking, and escalation at defined DPD thresholds — running daily, automatically, rather than depending on someone remembering to check AR aging that day. (We cover this in depth in our AR aging and collections playbook.)

2. Compliance monitoring. Tracking the 24-hour IRN cancellation window, weekly GSTIN status checks, and TDS variance detection — compliance deadlines that don't wait for someone to notice them manually. (See our GST e-invoicing guide.)

3. Smart billing. Auto-generating invoices that are due, flagging subscriptions that haven't been billed yet — a task that's purely about consistency, not judgment.

4. Period close routing. Automatically routing backdated or unusual entries based on materiality, escalating only what genuinely needs CFO review. (See our period close checklist.)

5. Revenue anomaly detection. Continuously scanning for unusual revenue patterns — a spike, a drop, a duplicate invoice — well before month-end close, when it's much easier to fix.

6. Renewal monitoring. Running the 180/90/30/7-day alert cadence automatically, so renewal risk is visible months in advance, not discovered a week before contract expiry. (See our renewal pipeline guide.)

7. Customer intelligence. Recalculating customer health scores continuously, so a declining account gets flagged as soon as the signal appears — not whenever someone happens to review that account next.

The Principle That Actually Matters: Agents Execute, Humans Decide

Here's the distinction that separates useful automation from something that should make any finance leader nervous: these agents handle repetitive execution, not judgment calls.

Churn treatment decisions, bad debt write-offs, expansion billing terms, and period close approvals for material entries should always stay with a human — specifically, someone with the authority and context to make that call, with a clear record of who decided what and when.

The value of automation here isn't removing the CFO from decisions that matter — it's making sure the CFO's attention is spent only on decisions that actually need it, instead of buried under the routine, repetitive tasks that don't.

What a Day Actually Looks Like With This in Place

Instead of starting the morning by manually checking AR aging, scanning for compliance deadlines, and reviewing the renewal pipeline one account at a time, a finance team wakes up to:

  • Dunning sequences already sent for genuinely overdue accounts
  • Any compliance deadline within its critical window already flagged
  • Any account showing early churn risk already surfaced, with months of runway to act
  • A clear queue of the handful of decisions that actually need a human — and nothing else cluttering that queue

This is precisely the architecture behind Fincelo's 7 AI agents — Collections, Compliance Guardian, Smart Billing, Period Close, Revenue Anomaly, Renewal, and Customer Intelligence — each automating the repetitive execution work of SaaS revenue operations, while every material decision stays exactly where it belongs: with your finance team.

See Fincelo's 7 AI agents in action →


Fincelo is an agentic AI-powered SaaS billing and revenue intelligence platform, built for Series A/B India SaaS companies and their CFOs.

Period Close Checklist for SaaS Finance Teams

 

Why Period Close Takes Longer Than It Should

For most SaaS finance teams, month-end close is the single most time-pressured recurring task on the calendar — and yet, for many teams, it's still done the same manual way it was when the company had a fraction of the customers it has today. The checklist below is the version that scales.

The Core Period Close Checklist

1. Reconcile invoicing against contracts. Confirm every active contract that should have generated an invoice this period actually did — and that no invoice was generated in error, without a corresponding valid contract.

2. Update the revenue recognition schedule. Confirm the amount recognized this period, across every active contract, matches what the deferred revenue waterfall says should be recognized — accounting for any new contracts, cancellations, or mid-term changes.

3. Reconcile deferred revenue. The deferred revenue balance on your balance sheet should tie out precisely to the sum of remaining unrecognized amounts across all active contracts. Any variance here needs to be understood and resolved, not rounded away.

4. Handle backdated and unusual entries. Any entry that needed correction — a late contract amendment, a billing error caught after the fact — needs a defined process, not an ad hoc decision made under closing-day time pressure.

5. Reconcile GST filings against invoices. Your GSTR-1 data should match your actual e-invoices for the period, with any variance flagged and explained before filing.

6. Reconcile TDS against Form 26AS. Confirm TDS credits reflected in Form 26AS match what was expected based on customer deductions, and flag genuine mismatches for follow-up.

7. Update AR aging and bad debt provisioning. Recalculate aging buckets based on current data, and apply your bad debt provisioning policy consistently — not just for the accounts that happen to be top of mind.

8. Reconcile intercompany transactions (if multi-entity). Confirm intercompany transactions are properly recorded on both sides and correctly eliminated in consolidation.

9. Update ARR, MRR, and NRR. These metrics should reflect the period's actual activity — new business, expansion, contraction, and churn — accurately, not as a rough approximation.

The Materiality Question: What Actually Needs a Human Decision?

Not every entry needs the same level of scrutiny, and treating every adjustment identically is part of why close takes longer than necessary. A practical approach uses materiality thresholds:

  • Small, immaterial adjustments can close automatically, without requiring individual sign-off for each one
  • Moderate adjustments should be flagged for CFO review before the books are finalized
  • Material adjustments — anything genuinely significant relative to the business — should require both CFO and controller review before close

The specific thresholds should reflect your business's actual scale and risk tolerance, but the principle — routing decisions by materiality rather than treating every entry identically — is what actually makes close faster without sacrificing rigor where it matters.

Where Manual Close Actually Breaks Down

The checklist above isn't complicated in theory. What makes it slow in practice, for most finance teams, is that each step requires pulling data from a different source — the billing system, the contract repository, the GST portal, the bank statement — and manually cross-checking them against each other. At any real scale, this becomes the primary reason close takes days instead of hours.

What This Should Look Like, Properly Automated

A period close process built for scale should:

  • Have every reconciliation checkpoint above running continuously through the month, not compressed into a few frantic days at month-end
  • Route entries automatically by materiality, escalating only what genuinely needs human judgment
  • Flag variances the moment they appear — a GST mismatch or a deferred revenue discrepancy shouldn't wait until close day to surface
  • Give finance leadership a clear, real-time view of close progress, not a black box that either finishes or doesn't

This is exactly the kind of automated, materiality-routed period close Fincelo's Period Close Agent runs for India SaaS companies — continuous reconciliation throughout the month, with only genuinely material decisions ever reaching the CFO's desk.

See how Fincelo automates period close →


Fincelo is an agentic AI-powered SaaS billing and revenue intelligence platform, built for Series A/B India SaaS companies and their CFOs.

Contract Intelligence: Why Manual Data Entry Costs Revenue

 

The Revenue Leak Hiding in Your Contract PDFs

Here's a quiet problem most SaaS finance teams don't realize they have until someone goes looking: contracts sit as PDFs, someone manually re-types the key terms into the billing system, and every re-typing is a fresh opportunity for a small error — an error that, multiplied across every contract in your book, adds up to real, measurable revenue leakage.

Where Manual Contract Entry Actually Fails

Price escalation clauses get missed. A 3-year contract with a 10% price increase built in at renewal is easy to catch when someone's looking directly at the contract — and easy to miss entirely when someone's re-typing terms into a billing system from memory of "what the deal generally was."

Floor quantities and minimum commitments get lost. Many SaaS contracts include minimum usage or seat commitments — if the person handling billing doesn't carry that detail forward correctly, a customer using fewer seats than their contractual minimum might get billed less than they actually owe, silently, for the life of the contract.

Auto-renewal terms are inconsistently tracked. Whether a contract auto-renews, and under what notice period, directly affects your renewal pipeline timing — get this wrong, and either you miss a genuine renewal opportunity, or you surprise a customer with an unexpected renewal they thought required their explicit sign-off.

Billing frequency mismatches. A contract negotiated as annual billing that accidentally gets set up as a different cadence in the billing system creates a mismatch that can go unnoticed for months, especially at any real contract volume.

Why This Compounds Rather Than Staying Small

A single manual entry error is a small problem. The reason this becomes a real issue at scale is that these errors don't get caught by normal review processes — nobody re-reads every contract line by line to confirm the billing system matches, because that's exactly the manual, repetitive work the original data entry was already supposed to have handled correctly.

By the time a discrepancy surfaces — often during an audit, a renewal negotiation, or a customer dispute — it's frequently been quietly compounding for months or years.

What AI Contract Extraction Actually Solves

Modern AI contract extraction reads an uploaded contract PDF and pulls out the fields that actually matter for billing and revenue recognition:

  • Contract value and currency
  • Start date, end date, and term length
  • Billing frequency and payment terms
  • Price escalation clauses and their trigger dates
  • Floor quantities, minimum commitments, and true-up provisions
  • Auto-renewal terms and required notice periods

Done well, this takes a process that might take a finance team member 20-30 minutes per contract — reading, interpreting, and manually re-entering — down to under a minute, with the added benefit of consistency: the extraction logic applies the same standard every time, rather than depending on whoever happens to be doing data entry that day.

The Trust Question: Can You Actually Rely on Automated Extraction?

This is a fair question, and the honest answer is: verification matters. A well-built contract intelligence system should show its extracted fields clearly, alongside the source contract, so a human can quickly confirm accuracy — and importantly, it should get better over time, learning from corrections rather than making the same category of mistake repeatedly.

The goal isn't removing human judgment entirely from contract review — it's removing the repetitive, error-prone manual re-typing, so the human attention that remains is spent verifying and handling genuine edge cases, not doing rote data entry.

Why This Is Foundational, Not Just Convenient

Contract intelligence isn't just a time-saver — it's the foundation everything downstream depends on. Your revenue recognition schedule, your renewal pipeline, your billing accuracy, and your GST treatment all depend on the contract terms being correctly captured in the first place. Get this step wrong, and every downstream process inherits the error.

This is exactly why Fincelo starts with AI contract extraction as a core capability — accurately capturing contract terms in under 60 seconds, so everything built on top of that data is trustworthy from the start.


AI contract extraction pulling key terms from a SaaS contract PDF



See Fincelo's contract intelligence in action →


Fincelo is an agentic AI-powered SaaS billing and revenue intelligence platform, built for Series A/B India SaaS companies and their CFOs.

AR Aging & Collections Playbook for SaaS Companies

 

The Uncomfortable Truth About SaaS Collections

Recurring revenue creates an illusion of predictability — but predictable billing doesn't mean predictable collection. An invoice that goes unpaid for 60 days isn't just a delayed payment; depending on your accounting policy, it may need to be provisioned as potential bad debt, and it's quietly distorting your cash flow projections the entire time it sits unresolved.

A proper AR aging and collections process exists to catch this early, systematically — not reactively, once someone happens to notice a large balance.

AR Aging Buckets: The Foundation

Most finance teams organize outstanding receivables into Days Past Due (DPD) buckets:

  • 0-30 days — normal, expected range for most payment terms
  • 31-60 days — worth active attention; this is where a proactive follow-up sequence should already be underway
  • 61-90 days — genuine concern; escalation beyond routine reminders is warranted
  • 90+ days — high risk; this is typically the threshold where bad debt provisioning starts being considered, depending on your accounting policy

The value of these buckets isn't just organizational — it's that different DPD tiers warrant genuinely different actions, not the same generic reminder email sent later.

Dunning: Escalation, Not Repetition

A good dunning sequence isn't the same email sent three times with different subject lines. It should escalate in tone and channel as an invoice ages:

  • Early (a few days overdue) — a friendly, automated reminder; most overdue invoices at this stage are simple oversights, not genuine payment problems
  • Mid-range — a more direct communication, potentially involving the account owner directly, not just an automated system
  • Late-stage — this is where a real conversation is warranted — understanding why payment hasn't happened, whether it's a cash flow issue on the customer's side, a dispute over the invoice itself, or something else entirely

Promise-to-Pay: Tracking Commitments, Not Just Reminders

When a customer says "we'll pay by Friday," that commitment needs to be tracked as a specific, dated promise — not treated the same as an invoice that's simply sitting unpaid with no communication at all. A customer who's engaged and has given a specific commitment is a fundamentally different collections situation than one who's gone silent, and treating them identically wastes effort and risks damaging a relationship that didn't need escalation.

Payment Scoring: Not All Customers Age the Same Way

A customer with a consistent history of paying 5 days late, every cycle, is a different risk profile than a customer who's always paid on time but is suddenly 45 days overdue for the first time. A payment score that accounts for historical behavior, not just current status, helps a collections team correctly prioritize attention — the "always a little late" customer might not need urgent escalation, while the "sudden change in behavior" customer might need it more than their current DPD bucket alone would suggest.

The Real Cost of Getting This Wrong

Poor AR management doesn't just mean cash sitting uncollected longer than necessary — it compounds:

  • DSO (Days Sales Outstanding) creeps up, distorting cash flow forecasts
  • Bad debt provisioning decisions get made too late, or too generously, without a systematic threshold behind them
  • Customer relationships can be genuinely damaged by generic, poorly-timed dunning that doesn't account for context — chasing a customer over an invoice that's actually already been paid (a common issue when TDS deductions aren't properly reconciled) is a particularly avoidable, relationship-damaging mistake

What This Should Look Like, Automated

A well-run collections process should automatically:

  • Bucket every invoice by DPD, continuously, not as a monthly manual exercise
  • Send escalating dunning communications on a defined schedule, adapted to each customer's payment history
  • Track promise-to-pay commitments as distinct, dated items requiring follow-up
  • Flag genuinely high-risk accounts for bad debt review, based on a consistent threshold — not ad hoc judgment calls made under time pressure

This is exactly the kind of continuous, automated collections workflow Fincelo's Collections Agent runs daily for India SaaS companies — freeing finance teams from manual AR chasing while keeping every customer relationship handled appropriately for their actual situation.

See how Fincelo automates collections →


Fincelo is an agentic AI-powered SaaS billing and revenue intelligence platform, built for Series A/B India SaaS companies and their CFOs.

Multi-Entity Revenue Consolidation for India SaaS Companies

 

The Moment Your Simple Finance Stack Stops Being Simple

Most India SaaS companies start with a single legal entity, one currency, and finance operations simple enough to manage without much dedicated infrastructure. Then international expansion happens — a US subsidiary, maybe a UK entity — and suddenly the finance function needs to answer a much harder question: what does "consolidated revenue" even mean across three currencies and three legal entities?

What Multi-Entity Actually Requires

Once you have more than one legal entity, your finance function needs to handle:

Entity-level books — each entity needs its own general ledger, its own compliant financial statements, and its own tax filings, because each is a separate legal and tax jurisdiction.

Currency translation — revenue booked in USD by your US subsidiary needs to be translated into your reporting currency (often INR, if that's your parent entity) for consolidated reporting — and the FX rate used, and when it's applied, has real accounting implications.

Intercompany transactions — if your India entity provides services to your US entity (engineering, support, shared infrastructure), those transactions need to be properly recorded, eliminated in consolidation, and priced according to transfer pricing rules to stay compliant.

Consolidated reporting — your board and investors want one picture of the business, not three separate P&Ls they have to mentally combine themselves.

The FX Question Nobody Gets Right the First Time

Here's a rule that's easy to state and surprisingly easy to violate in practice: foreign exchange gains and losses should never be recorded as revenue. They belong in Other Income or Finance Costs, as their own distinct line items.

Why this matters: if FX movements bleed into your revenue figures, your ARR and NRR numbers become distorted by currency fluctuation rather than reflecting actual business performance. A finance team trying to explain to a board why NRR moved when nothing actually changed with customers — just the rupee-dollar exchange rate — is a conversation worth avoiding entirely by keeping these separated correctly from the start.

Intercompany Transactions: The Audit Red Flag Waiting to Happen

Intercompany transactions that aren't properly documented and eliminated in consolidation are one of the most common issues auditors flag in multi-entity SaaS companies. Every intercompany transaction needs:

  • A documented rationale (often tied to transfer pricing policy)
  • Proper recording on both sides of the transaction (as an expense on one entity's books, income on the other's)
  • Elimination in the consolidated view, so the group's revenue isn't artificially inflated by the company effectively "selling to itself"

What Good Consolidated Reporting Actually Looks Like

At minimum, your finance team should be able to produce, on demand:

  • Entity-level P&L and balance sheet, in each entity's local currency
  • A properly translated, consolidated view in your reporting currency
  • ARR/MRR/NRR calculated at the consolidated level, not just summed naively across entities (which can misrepresent things if currency movements aren't handled correctly)
  • Clean intercompany elimination, with a documented trail an auditor can actually follow

Why This Usually Gets Built Too Late

Most companies don't think about multi-entity infrastructure until they're already expanding internationally — at which point it becomes a scramble, often solved with a patchwork of spreadsheets bridging what should be a properly integrated system. By the time an auditor or investor asks pointed questions about consolidation methodology, "we're still figuring that out" is not the answer anyone wants to give.

This is exactly the kind of multi-entity, multi-currency consolidation Fincelo is built to handle from day one — proper entity-level books, automatic FX treatment that never touches revenue, and a genuinely consolidated view your board can actually trust.

See how Fincelo handles multi-entity consolidation →


Fincelo is an agentic AI-powered SaaS billing and revenue intelligence platform, built for Series A/B India SaaS companies and their CFOs.

Deferred Revenue Explained: A Guide for SaaS Finance Teams

 

The Balance Sheet Item That Confuses Almost Every First-Time SaaS Founder

Here's a scenario that trips up nearly every founder who hasn't run finance at a subscription business before: a customer pays ₹12,00,000 upfront for an annual contract, the money is sitting in the bank, and yet the accountant says you've only "earned" a fraction of it. Where did the rest of it go?

It didn't go anywhere. It's sitting on your balance sheet as deferred revenue — and understanding this properly is fundamental to reading your own financials correctly.

What Deferred Revenue Actually Is

Deferred revenue is a liability, not income. It represents an obligation: you've been paid, but you still owe the customer the service they paid for. As you actually deliver that service — month by month, across the contract term — the corresponding portion moves from deferred revenue on your balance sheet into recognized revenue on your P&L.

This is the direct, practical consequence of ASC 606's core principle: revenue is recognized as performance obligations are satisfied, not when cash changes hands.

A Simple Example

A customer pays ₹12,00,000 for a 12-month contract, upfront, on January 1st.

  • Day 1: ₹12,00,000 in cash. ₹12,00,000 in deferred revenue. ₹0 recognized as revenue.
  • End of January: 1/12th of the contract has been delivered. ₹1,00,000 moves from deferred revenue into recognized revenue. ₹11,00,000 remains deferred.
  • This continues each month until, at the end of month 12, the full ₹12,00,000 has been recognized and deferred revenue for this contract is zero.

Simple with one contract. The complexity shows up when you have hundreds of contracts, each starting on different dates, with different terms, some with mid-contract upgrades or downgrades that need to adjust the remaining schedule.

Why This Matters More Than It Might Seem

For your own decision-making: if you're looking at cash in the bank as a proxy for how the business is doing, you're missing the obligation side of the ledger entirely. A company can have healthy cash and a deeply troubled underlying business if deferred revenue isn't being tracked and understood properly.

For investors and board members: deferred revenue balance, and how it's trending, is a genuine signal of business health. A shrinking deferred revenue balance relative to new bookings can indicate a slowing sales motion, even if current-period recognized revenue still looks fine.

For audits: an auditor will specifically test whether your deferred revenue schedule ties out correctly to your actual contracts. A revenue recognition schedule that was built or is being maintained manually, especially at any real scale, is exactly the kind of thing that turns into a lengthy, painful part of an audit.

Where Manual Deferred Revenue Tracking Breaks Down

The math itself, per contract, isn't hard. What breaks manual tracking is volume and change:

  • Mid-contract changes — an upgrade or downgrade partway through a term needs to correctly adjust the remaining recognition schedule, not just apply going forward from whenever someone remembers to update the spreadsheet
  • Multi-year contracts with escalation — a 3-year deal with a price increase in year 2 needs its deferred revenue schedule to reflect that from the start
  • Cancellations mid-term — the remaining deferred balance needs to be handled correctly (recognized immediately, refunded, or written off, depending on the specific circumstances), not just left sitting incorrectly on the books

What This Should Look Like, Properly Automated

A deferred revenue schedule should be:

  • Generated automatically the moment a contract is signed and invoiced, not built manually after the fact
  • Adjusted automatically when a contract changes, rather than requiring someone to remember to update every affected future period
  • Visible at any moment as a real-time waterfall — not something rebuilt once a quarter for board reporting

This is exactly the kind of automated revenue recognition schedule Fincelo builds and maintains for every contract, updated in real time as your actual billing and contract data changes.

See your deferred revenue waterfall, automatically built →


Fincelo is an agentic AI-powered SaaS billing and revenue intelligence platform, built for Series A/B India SaaS companies and their CFOs.

How to Build a Renewal Pipeline That Prevents SaaS Churn

 

Most SaaS Companies Find Out About Churn Too Late

Here's a pattern we see constantly: a customer's contract quietly approaches its end date, nobody flags it internally until a week before expiry, and by then there's no real time left to address whatever issue was driving them toward non-renewal. The churn wasn't inevitable — it just wasn't caught early enough to do anything about it.

A good renewal pipeline fixes this by turning "renewal" from a single deadline into a monitored process with real lead time.

The Core Idea: Alert Early, Not Just Once

Rather than a single "contract ends in 30 days" reminder, an effective renewal pipeline uses a staged alert cadence — commonly at 180, 90, 30, and 7 days before contract end:

  • 180 days out — early visibility. Plenty of time to address any brewing issues, plan an expansion conversation, or simply confirm the relationship is healthy
  • 90 days out — start active renewal conversations for anything not already progressing
  • 30 days out — escalate anything still unresolved; this is the point where a stalled renewal needs direct attention, not just a check-in
  • 7 days out — final urgency flag; anything still open here needs immediate action

The point of staging alerts this way isn't just reminders — it's giving your team enough runway to actually change the outcome, rather than just documenting that churn happened.

Health Scoring: Knowing Which Renewals Need Attention

Not every renewal needs the same level of proactive attention. A well-built renewal pipeline scores accounts across multiple dimensions to flag risk before the renewal date even approaches:

  • Payment behavior — a customer with a clean payment history is a different risk profile than one that's been chronically late
  • Product usage — declining usage is often the earliest real signal of churn risk, well before any contract conversation happens
  • Support engagement — a spike in support tickets, or conversely, total silence from a previously engaged account, can both be meaningful signals
  • Contract terms — auto-renewal clauses, price escalation terms, and grace period provisions all affect how a renewal should actually be handled

Grace Periods: The Detail Most Pipelines Get Wrong

When a contract lapses without a signed renewal, what happens next matters enormously — and it shouldn't be a judgment call made in a panic. A defined grace period (commonly 30-45 days) gives room to complete a renewal in progress without immediately suspending customer access, which would only accelerate churn rather than prevent it.

But grace periods need boundaries too: if a renewal genuinely isn't happening, continuing to extend access indefinitely just delays the inevitable while creating unbilled revenue exposure.

What Good Renewal Data Actually Looks Like

At minimum, a proper renewal pipeline should track, per account:

  • Contract end date and current status (monitoring, in negotiation, signed, churned)
  • A calculated health score, updated regularly — not just at renewal time
  • Whether there's a genuine expansion opportunity alongside the renewal itself
  • Price escalation terms already built into the contract, so renewal quotes reflect what was actually agreed, not a guess

Why This Usually Breaks Down in Practice

The theory here isn't complicated. The reason most companies still struggle with it is operational: tracking dozens or hundreds of renewal dates, health signals, and alert cadences manually, in a spreadsheet, simply doesn't scale — and the moment it doesn't scale, the alerts stop firing reliably, and you're back to finding out about churn a week before it happens.

This is exactly the kind of continuous monitoring Fincelo's Renewal Agent automates — running the 180/90/30/7-day cadence automatically, scoring account health continuously, and surfacing genuinely at-risk renewals to your team with enough lead time to actually act.

See how Fincelo automates renewal monitoring →


Fincelo is an agentic AI-powered SaaS billing and revenue intelligence platform, built for Series A/B India SaaS companies and their CFOs.

TDS on SaaS Subscriptions in India: Section 194J Explained

 

TDS on SaaS Payments: A Compliance Detail That's Easy to Get Wrong

If you sell SaaS to Indian business customers, there's a good chance a portion of your customers are deducting TDS (Tax Deducted at Source) before paying your invoice — and if your finance team isn't actively reconciling this, you're likely sitting on a growing gap between what you invoiced and what actually landed in your bank account.

Why TDS Applies to SaaS at All

Under the Income Tax Act, payments for "fees for technical services" or royalty-like payments are subject to TDS under Section 194J, typically at 2% for many technical service categories (rates and classifications can vary based on the specific nature of the service — this is a general framework, not tax advice for your specific situation).

Many Indian businesses treat SaaS subscription payments as falling under this category, meaning when your customer pays your invoice, they deduct the applicable TDS percentage and remit it directly to the government on your behalf — you receive the net amount, not the full invoice value.

The Reconciliation Problem

Here's where it gets operationally messy: your customer's TDS deduction shows up in your Form 26AS, a tax credit statement maintained by the Income Tax Department — but it doesn't automatically show up anywhere in your own billing system.

This creates a structural mismatch:

  • Your invoice says ₹1,00,000
  • Your customer pays ₹98,000 (after 2% TDS)
  • Your books, if not adjusted, show an "outstanding" ₹2,000 that isn't actually outstanding — it's a TDS credit sitting in Form 26AS

Multiply this across dozens or hundreds of customers, and manual reconciliation between "what we invoiced," "what we received," and "what shows in 26AS" becomes a genuinely significant monthly task — and a common source of AR aging reports that look worse than reality.

The Real Risk: Mismatches That Compound

The problem isn't just administrative annoyance. If your books don't correctly account for TDS:

  • Your AR aging reports overstate genuinely overdue amounts, since TDS-adjusted invoices look "unpaid" when they're actually fully settled
  • Your tax credit claims can be understated if TDS deducted by customers isn't properly matched and claimed
  • Audit reconciliation becomes a manual, time-consuming exercise instead of a straightforward check

What a Proper TDS Workflow Looks Like

A finance team handling this well should have a system that:

  • Flags customers where TDS applicability is expected, based on customer type and payment history
  • Automatically nets the expected TDS amount against the invoice, so AR aging reflects reality rather than a false "overdue" balance
  • Reconciles actual TDS credits from Form 26AS against expected deductions, flagging any variance for review — not just assuming every payment matches perfectly
  • Keeps this reconciliation continuous, not a quarterly scramble before tax filing deadlines

Why This Matters Beyond Compliance

Getting TDS reconciliation right isn't just about avoiding tax problems — it directly affects how accurately you understand your own collections performance. A collections team chasing customers over invoices that are actually fully paid (just TDS-adjusted) wastes time and can genuinely damage customer relationships over a misunderstanding that a proper reconciliation process would have caught automatically.

This is exactly the kind of continuous, automated reconciliation Fincelo builds into its compliance workflows for India SaaS companies.

See how Fincelo handles TDS reconciliation automatically →


Fincelo is an agentic AI-powered SaaS billing and revenue intelligence platform, built for Series A/B India SaaS companies and their CFOs. This post is for general informational purposes and does not constitute tax advice — consult a qualified tax professional for guidance specific to your business.

ARR vs MRR vs NRR: SaaS Metrics India CFOs Must Track

 

Three Metrics, Three Different Questions

Ask five people in a SaaS company to define NRR and you'll often get five slightly different answers. Part of the confusion is that ARR, MRR, and NRR aren't really measuring the same thing — they answer three genuinely different questions about your business.

ARR: How Big Is the Business, Right Now?

Annual Recurring Revenue is your total contracted recurring revenue, normalized to a yearly figure. If you have ₹2,00,00,000 in active annual-equivalent subscriptions across all customers, that's your ARR — regardless of whether individual contracts are billed monthly, annually, or over three years.

ARR answers: "How big is this business today?" It's the headline number investors and boards look at first.

MRR: What's the Monthly Cash Engine Look Like?

Monthly Recurring Revenue is simply ARR divided by 12 — but it's more useful when you break it into its components:

  • New MRR — revenue from brand-new customers this month
  • Expansion MRR — additional revenue from existing customers upgrading or adding seats
  • Contraction MRR — revenue lost from existing customers downgrading
  • Churned MRR — revenue lost from customers who cancelled entirely

MRR answers: "What's actually moving, month to month, and in which direction?" This is the metric that tells you why your ARR is changing, not just that it's changing.

NRR: Are Your Existing Customers Worth More or Less Over Time?

Net Revenue Retention measures revenue from your existing customer base only — comparing what they're paying now versus what they were paying 12 months ago, excluding any revenue from new customers acquired during that period.

The formula: (Starting ARR + Expansion − Contraction − Churn) ÷ Starting ARR

An NRR above 100% means your existing customers are spending more over time than they were a year ago — even before counting a single new customer. An NRR below 100% means you're running just to stand still, needing constant new-customer acquisition to offset the leakage from your existing base.

Why NRR Is the One Investors Actually Obsess Over

Here's the thing about ARR growth: it can hide a genuinely troubled business. A company can show impressive ARR growth purely from aggressive new customer acquisition, while its existing customer base is quietly churning or downgrading underneath. NRR is what exposes that — it's the metric that answers "would this business still grow if we stopped signing new customers tomorrow?"

For that reason, most Series A/B investors will ask about NRR specifically, separate from ARR growth, when evaluating a SaaS company's health.

The Practical Problem: These Numbers Are Genuinely Hard to Calculate Correctly

In theory, this is simple math. In practice, most finance teams calculating these metrics manually run into real problems:

  • Mid-cycle upgrades and downgrades need to be correctly attributed to the right month, not just batched at renewal
  • Multi-year contracts need to be normalized correctly into a true annual-equivalent figure, not just divided by contract length
  • Currency conversion for international customers needs a consistent methodology, not whatever the spot rate happened to be on invoice day

Getting any of these wrong doesn't just create a slightly-off number — it can flip your NRR from a story investors like to one that raises hard questions in a board meeting.

What This Should Look Like

ARR, MRR, and NRR should be live numbers, calculated automatically from your actual billing and subscription data — not a monthly spreadsheet exercise reconstructed from invoices and contract PDFs.

This is exactly the kind of real-time revenue waterfall Fincelo builds automatically for India SaaS companies, so these numbers are always accurate and always current — not just accurate on the day someone last rebuilt the spreadsheet.


ARR MRR NRR SaaS revenue metrics comparison chart



See your real ARR, MRR, and NRR — automatically →


Fincelo is an agentic AI-powered SaaS billing and revenue intelligence platform, built for Series A/B India SaaS companies and their CFOs.

GST E-Invoicing for SaaS: IRN, QR Codes & 24-Hour Rule

 

GST E-Invoicing Isn't Optional Anymore — Here's What SaaS Companies Need to Know

If your SaaS company crosses the applicable turnover threshold, GST e-invoicing isn't a nice-to-have — it's a legal requirement, and getting it wrong has real financial consequences: rejected input tax credit claims for your customers, compliance penalties, and reconciliation headaches during GSTR-1 filing.

Here's what actually matters, practically, for a SaaS finance team.

What Is an IRN, and Why Does It Matter?

Every e-invoice you generate needs to be reported to the Invoice Registration Portal (IRP), which validates it and returns a unique Invoice Reference Number (IRN) — a cryptographic hash tied to your invoice details. Without a valid IRN, your invoice is not considered a valid tax invoice under GST law, regardless of how correctly everything else on it is formatted.

Along with the IRN, the IRP returns a QR code that must be printed on the invoice itself — this is what allows GST officers and your customers to instantly verify the invoice's authenticity.

The 24-Hour Cancellation Window Nobody Warns You About

Here's the detail that catches most finance teams off guard: once an IRN is generated, you have exactly 24 hours to cancel it if there's an error. After that window closes, cancellation is no longer possible through the IRP.

If you discover a mistake after 24 hours — wrong amount, wrong GSTIN, wrong line items — you cannot simply cancel and reissue. Instead, you need to issue a credit note with its own new IRN to correct the original invoice. This is a fundamentally different correction mechanism, and treating it like a simple cancel-and-redo will create a mismatch in your GST records.

Practical takeaway: build a review step into your invoicing workflow that catches errors before the 24-hour window closes, not after — because the fix afterward is meaningfully more complex.

Common Mistakes We See SaaS Companies Make

1. Treating invoice date and revenue recognition date as the same thing. They're not — GST is triggered by the invoice date; ASC 606 revenue recognition follows the performance obligation timeline. (We cover this in detail in our ASC 606 guide.)

2. Not tracking GSTIN status changes. If a customer's GSTIN is suspended or cancelled after you've already generated invoices against it, that creates a compliance gap that's easy to miss without active monitoring.

3. Manual reconciliation between e-invoices and GSTR-1. Doing this by hand, every filing period, is exactly the kind of repetitive, error-prone task that shouldn't require manual effort every single month.

How This Should Actually Work

A properly automated e-invoicing workflow should:

  • Generate the IRN and QR code automatically at the moment of invoicing, with no manual portal interaction
  • Flag any invoice nearing the 24-hour cancellation window that hasn't been reviewed yet
  • Automatically route corrections past that window into the proper credit-note-with-new-IRN process
  • Keep GSTR-1 data pre-populated and reconciled against your actual invoice records, continuously — not just at filing time

This is exactly the kind of compliance workflow Fincelo automates for India SaaS companies, so your finance team isn't manually shepherding every invoice through the IRP.


GST e-invoice IRP portal IRN QR code generation flow



See how Fincelo handles GST e-invoicing automatically →


Fincelo is an agentic AI-powered SaaS billing and revenue intelligence platform, built for Series A/B India SaaS companies and their CFOs.

ASC 606 Revenue Recognition for India SaaS Companies: 2026 Guide

Why ASC 606 Is Harder for India SaaS Companies Than Anyone Tells You

If you're a finance leader at an India-based SaaS company selling to US or global customers, you've probably heard the same advice everywhere: "just follow the 5-step ASC 606 model." What almost nobody tells you is what happens when that model collides with GST, multi-year contracts billed in INR, and a finance team doing period close in a spreadsheet at 11pm.

This guide covers ASC 606 the way it actually shows up for India SaaS companies — not the textbook version.

What ASC 606 Actually Requires (The 5-Step Model, Briefly)

ASC 606 — and its international equivalent, IFRS 15 — governs when and how much revenue you're allowed to recognize from a customer contract. The five steps are:

  1. Identify the contract with a customer
  2. Identify the performance obligations — what you're actually promising to deliver
  3. Determine the transaction price — the total amount you expect to be entitled to
  4. Allocate the price across each performance obligation
  5. Recognize revenue as each obligation is satisfied

That's the theory. Here's where it actually gets complicated for a SaaS company billing annually or over multiple years.

The Real Problem: Invoice Date Is Not Recognition Date

The single most common mistake we see in India SaaS finance teams: treating the invoice date as the revenue recognition date.

If a customer signs a 3-year contract and pays ₹36,00,000 upfront, you have not earned ₹36,00,000 of revenue the day that invoice clears. Under ASC 606, that amount needs to be recognized ratably over the 3-year service period — typically month by month, as the service is actually delivered.

This means:

  • The cash hits your bank account on day one
  • The revenue is recognized gradually, over 36 months
  • The difference sits on your balance sheet as deferred revenue — a liability, not income, until it's earned

Get this wrong, and your P&L looks nothing like your actual business performance — which becomes a serious problem the moment an investor, auditor, or board member asks to see your numbers.

Where GST Makes This Even Harder

Here's the part most ASC 606 guides — written for US audiences — never mention: your GST treatment and your revenue recognition schedule are two completely separate calculations, and conflating them is a common, costly mistake.

GST is charged and remitted based on the invoice date and the applicable GST treatment type (registered regular, unregistered, overseas/export, SEZ, and several others — India has roughly 10 distinct GST treatment scenarios that a B2B SaaS company can encounter). Revenue recognition under ASC 606 follows the performance obligation timeline, which has nothing to do with when GST becomes payable.

A finance team that tries to force these two into the same schedule usually ends up with either:

  • GST filings that don't reconcile cleanly with revenue reports, or
  • A revenue recognition schedule that's quietly being distorted to make the accounting "easier" — which is exactly the kind of thing that turns into a real problem at audit time

Multi-Year Contracts: The Escalation Clause Trap

Many India SaaS contracts include built-in price escalation — for example, a 3-year deal where the price increases 10% each renewal year. Under ASC 606, if that escalation is already specified in the original contract, it typically needs to be factored into the total transaction price calculation from day one — not treated as a fresh new sale each year.

This is a detail that's easy to miss manually, and one that compounds — a small error in year one of a 3-year schedule doesn't just misstate one month, it distorts the entire remaining recognition curve.

Period Close: Where This All Comes Together (Or Falls Apart)

At month-end, a finance team needs to answer, for every active contract:

  • How much revenue was actually earned this period?
  • How much remains deferred?
  • Does any backdated entry (a late contract amendment, a correction) need special handling?

Most finance teams handle backdated or unusual entries with what we think of as a materiality-based decision:

  • Small, immaterial adjustments — close automatically, no separate review needed
  • Moderate adjustments — flagged for CFO review before the books close
  • Material adjustments — require both CFO and controller sign-off before anything is finalized

The mistake we see most often isn't getting the accounting theory wrong — it's not having a consistent, repeatable process for making this judgment call every single month, which is exactly when errors creep in.

What This Actually Looks Like When It's Automated

This entire process — invoice-to-recognition separation, GST treatment applied independently of revenue timing, multi-year escalation clauses correctly modeled from contract signing, and a consistent materiality-based period close — is exactly what Fincelo was built to handle automatically for India SaaS companies, without asking your finance team to rebuild the logic in a spreadsheet every month.

If you're currently doing any part of this manually, it's worth seeing what a platform built specifically for this problem looks like.


ASC 606 revenue recognition waterfall chart for a SaaS company
ASC 606 revenue recognition waterfall chart for a SaaS company

Start a 14-day free trial at fincelo.app →



Fincelo is an agentic AI-powered SaaS billing and revenue intelligence platform, built for Series A/B India SaaS companies and their CFOs.

Powered by Blogger.