Rish, my recommendation is a conditional go—but I would change the product’s positioning, initial customer segment, and claims about “exact FX leakage.”

The stronger business is:

A provider-neutral export receivables and month-end close platform for Indian SaaS companies: reconcile invoices to bank deposits, explain deductions, and prepare invoice-linked compliance evidence—without changing payment providers.

Make FX cost analysis one module, not the entire company. Start with a finance-team application, build an API-ready architecture underneath it, and sell the API separately only after the workflow is proven.

The distinction matters commercially: identifying expensive FX might create a one-time project. Completing the monthly export close, resolving exceptions, and maintaining an evidence trail can create a recurring subscription.

This assessment reflects public information available on October 20, 2026. Product capabilities below are based on official documentation or vendor claims; I have not independently tested competitors, accessed live merchant accounts, or validated customer willingness to pay.

Your idea combines three potentially valuable jobs:

Financial reconciliation: Which invoices, payments, fees, refunds, and adjustments produced this bank deposit?

Cost assurance: Were the correct fees applied, and how expensive was the currency conversion?

Compliance preparation: Which invoices have sufficient remittance evidence, which declarations need preparation, and which bank-dependent items remain unresolved?

I would enter through the first and third jobs, then expand the second.

Correction 1: The authorization-time gap is not the FX markup

Comparing the authorization-time mid-market rate with the final INR deposit combines several different effects. A product that labels all of them “leakage” would produce misleading savings claims.

Using your example, the following is an illustrative decomposition—not current exchange rates or any provider’s actual pricing:

The ₹200 difference is not ₹200 of FX markup. In this example, ₹40 is the conversion spread relative to the chosen benchmark—and even that is not necessarily recoverable or avoidable.

The relevant calculation, with both rates expressed in INR per USD, is:

Benchmark spread (bps) = 10,000 × (Reference rate at conversion − Executed rate) ÷ Reference rate at conversion.

Here, that is approximately 48.3 basis points.

The product must distinguish observed costs, estimated costs, contractual overcharges, and potentially avoidable costs. Those are four different things.

Also, an indicative mid-market quote is not a guaranteed executable quote for that merchant, amount, payment method, or time window. Your marketing should say “benchmark spread” unless the provider’s contractual reference rate and conversion mechanics justify something more precise.

Correction 2: Some of the supposedly hidden information already exists

Stripe’s Balance Transaction object exposes fields including amount, fee, fee_details, net, source, and a nullable exchange_rate. Its payout reconciliation reports provide transaction-level attribution for supported automatic-payout flows. Therefore, the opportunity is not simply “reveal data processors hide”; it is combine fragmented information into a reliable, actionable record. Stripe Docs

The difficult cases are where the conversion timestamp is unknown, deductions occur across multiple intermediaries, references disappear between systems, or settlements combine transactions from different periods.

Correction 3: A document downloader is becoming a commodity

PayPal’s official India page says it introduced free, automatically generated weekly digital FIRA from February 2026. Stripe also documents a payment-advice process for international transactions in India. A standalone “get your remittance certificate” feature is therefore a weak foundation for a new SaaS company. PayPal

The more valuable question is:

“Can the finance team prove what each document covers, identify what is missing, and complete the close without reconstructing the chain manually?”

Do not treat FIRC, FIRA, eBRC, and export declarations as interchangeable

Your application needs separate records for each document and process.

DGFT’s framework allows exporters to self-certify eBRCs by matching bank-transmitted IRMs with invoice or shipping-bill details. Importantly, DGFT introduced bulk upload and API integration in August 2024; this is a real integration opportunity, not something that necessarily requires portal scraping. Exporter registration and controlled API access are part of that framework. chemexcil.in

GST documentation is more nuanced than “every exporter requires a FIRC”

The GST portal’s official refund manual requires BRC/FIRC details for services in the relevant export-refund workflow, while goods use shipping and export documentation. It also supports multiple BRC/FIRC references for one document and the same reference across multiple invoices. This supports a many-to-many evidence model, not a single certificate field attached to each invoice. GST Tutorial

But possessing a remittance document does not, by itself, establish export qualification, zero-rating, or refund entitlement. Keep tax eligibility and filing decisions with the customer’s authorized finance professional.

A significant change took effect on October 1, 2026

RBI’s 2026 regulations introduced an EDF declaration workflow for service exports, generally within 30 days after the invoice month ends, with provisions for consolidated monthly declarations and specified alternatives/extensions. For software exports in the domestic tariff area, the specified authority can be an Authorised Dealer or STPI. Reserve Bank of India

Be careful with implementation dates: the September 22 amendment changed the originally published realization periods from fifteen/eighteen months to nine/twelve months, respectively, including the relevant INR provision. Do not implement deadlines from the January text alone. TaxGuru

The framework also allows simplified bank closure based on exporter declarations for invoices up to ₹10 lakh, including quarterly bulk closure. Regulation therefore creates workflow demand while also simplifying parts of it. It does not automatically create a large, high-paying market. Reserve Bank of India

Product implication: build an effective-date-aware evidence and workflow engine—not a hardcoded “FIRC compliance checker.” Have an Indian FEMA/GST specialist approve the initial rules and exception handling.

The research found both broad substitutes and an unusually close emerging competitor.

These pages establish advertised scope, not independently verified accuracy, implementation speed, adoption, or retention.

Where you could still win

I would test this specific differentiation:

“For Indian SaaS exporters using multiple payment providers, we produce an invoice-to-bank-to-evidence close with minimal setup, transparent exceptions, and finance-team sign-off.”

That proposition must outperform three alternatives: native provider reports, an accountant’s spreadsheet, and a configurable reconciliation product.

Your defensibility cannot be “AI-powered,” “one API,” or “we have connectors.” Those are already present in competing propositions.

Recommended initial customer profile

I would first test India-incorporated SaaS and digital-service exporters with roughly:

• $100,000–$1 million in monthly foreign receipts, as a prospecting hypothesis rather than a hard qualification rule.
• Multiple payment sources, or enough transaction and exception volume to make the close painful.
• A small finance team and an external CA, with someone explicitly responsible for monthly reconciliation.

The buyer is likely the founder/CFO/head of finance. The daily user is more likely the controller, finance operations analyst, or accountant.

Complexity matters more than revenue alone. A company receiving five straightforward transfers each month may be a poor prospect despite substantial export revenue.

Why I would not launch with D2C

My prioritization would be to avoid combining financial reconciliation with goods-export documentation, returns, marketplace deductions, inventory movements, and customs workflows before the core product works.

That is a scope decision—not a claim that D2C has less pain. It may eventually be a valuable separate product configuration.

Why I would not start with freelancers

Free provider tools create a demanding price benchmark, and servicing many small accounts could turn document chasing into an expensive support operation. Lumeo, for example, advertises an individual plan at ₹499/month, although its site says the product is not yet live. That is not comparable enterprise pricing, but it illustrates the positioning pressure at the low end. PayPal

Qualify the legal entity before qualifying the payment provider

“Indian-founded SaaS” is not a sufficient customer definition.

Consider a US company charging customers through a US merchant account, while its Indian subsidiary invoices the US parent. Those are separate commercial relationships and receivables. Matching every US customer payment directly to the Indian subsidiary’s export invoice would be conceptually wrong.

Similarly, merchant-of-record arrangements require contract-specific modeling.

For version one, I would favor straightforward Indian legal-entity export flows and deliberately exclude complex intercompany and merchant-of-record structures.

Also, Stripe currently documents invite-only onboarding in India. Do not make your entire acquisition plan depend on newly created Stripe India accounts. Stripe Support

Sell a completed close, not another dashboard

The initial application should help a finance user answer four questions.

What has been paid and settled?
Show invoices, customer payments, processor balances, payouts, and bank credits. Keep “customer paid,” “bank settled,” and “regulatory evidence complete” as distinct statuses.

Why is the bank amount different?
Provide a gross-to-net explanation separating processing fees, FX conversion, taxes, refunds, reserves, bank charges, timing differences, and unresolved residuals.

What still needs attention?
Give each exception an owner, reason, supporting evidence, and next action. A missing bank reference should not be disguised as a successful fuzzy match.

Can we complete and evidence the month-end close?
Produce approved accounting exports, invoice-level evidence schedules, missing-document lists, and declaration-preparation packs.

The first customer deliverable

A useful first deliverable is a monthly export-close pack containing:

1. An invoice-to-payment-to-payout-to-bank reconciliation.
2. A fee and conversion analysis with clear confidence labels.
3. An evidence schedule and unresolved-exception register.
4. A reviewer-approved accounting export.

That is something a customer can evaluate against their existing process.

What I would exclude initially

Do not begin with money movement, currency execution, hedging, wallets, a full accounting system, automated tax-return filing, revenue recognition, or twenty payment integrations.

Also, do not promise to issue bank certificates or complete bank-controlled processes on your own.

Build the application for finance users first. Keep the underlying domain model and services API-ready, but wait to sell an embedded API until partners repeatedly ask for the same supported workflow.

Partly—and the exact coverage must be established using live customer data before significant engineering investment.

Establish a data-coverage contract for every supported integration

For each payment flow, document which amounts are directly observed, which can be deterministically derived, which are estimated, and which are unavailable.

This is especially important for pooled fees. Allocating a ₹1,000 bank charge proportionally across fifty invoices is a reasonable accounting policy in some contexts—but it is not proof that the bank charged exactly that amount against each invoice.

Likewise, when fees are deducted in USD before conversion, calculate the executed rate using the amount actually converted, not the original invoice amount.

The system should be able to say “unknown.” That is a trust feature.

For an initial implementation, I would use a modular monolith, PostgreSQL, object storage, a durable job queue, and integration workers. I would not start with microservices, a dedicated graph database, or a complex streaming platform.

The difficult scaling problem is likely to be heterogeneous financial data and exceptions—not raw request throughput.

A. Preserve immutable source evidence

Retain the original API payloads and uploaded files, with tenant, source account, retrieval time, source identifiers, and content hashes.

A reviewer should be able to trace a computed amount back to the original record. Re-imports should not silently change historical conclusions.

B. Model the financial chain explicitly

Create separate entities for invoices, payments, balance events, FX conversions, fees, payouts, bank credits, remittance documents, and declarations.

Connect them using value allocations, not just foreign keys or date similarity. One payment can cover several invoices; one invoice can have several payments; one payout can contain many payments, refunds, and adjustments.

Every allocation should record its amount, currency, evidence, matching method, confidence, and approval state.

C. Use deterministic reconciliation before AI

Start with exact transaction IDs, payout IDs, invoice references, bank references, and validated component totals.

Use controlled rules for known transformations. Use fuzzy matching only to propose candidates.

A useful stress test is a merchant with hundreds of identical $99 subscription payments. Amount and date alone are not enough to establish which invoice a remittance covers.

D. Maintain an auditable reconciliation subledger

A multi-currency subledger should track processor balances, receivables, fees, payouts in transit, refunds, reserves, and FX effects. Correct errors through traceable adjustments or reversals rather than overwriting history.

This should support the customer’s accounting system, not silently replace its booked revenue or exchange-rate policies.

Build invariants such as opening balance plus movements equaling closing balance, no double allocation, and payouts tying to their component records and bank receipts.

E. Treat reliability as a product feature

Use account-scoped idempotency keys, signed webhooks where supported, polling/backfills, retry queues, pagination checks, and explicit data-completeness indicators.

Handle late refunds, cross-month payouts, delayed documents, and historical corrections deliberately. A green reconciliation result based on an incomplete import is worse than a visible failure.

F. Use AI in bounded roles

AI can help extract document fields, classify descriptions, suggest mappings, and draft an exception explanation or bank email.

It should not invent missing amounts, certify a tax position, produce a fake remittance certificate, or approve an ambiguous allocation.

The valuable system is deterministic financial controls with assisted exception handling, not an LLM making accounting decisions.

Security and the regulatory boundary

Use least-privilege authorization, encrypted credentials, tenant isolation, role-based access, reviewer approvals, audit logs, tested backups, and explicit retention policies. Avoid collecting cardholder data you do not need.

Keep the initial product read-only and non-custodial. RBI’s 2025 Payment Aggregator Directions distinguish aggregation and settlement of customer funds from technology-only activities, and impose substantial authorization/capital requirements on payment aggregators. They specify ₹15 crore net worth at application and ₹25 crore by the end of the third financial year after authorization. Reserve Bank of India

That is a strong reason not to drift casually into collecting or settling money. Obtain a written legal-perimeter assessment; “we are SaaS” is not, by itself, a regulatory analysis.

These are pricing experiments and planning assumptions, not market-validated benchmarks.

Initial commercial structure

Historical diagnostic: ₹25,000 one-time.
Analyze a defined period, produce the close pack, and identify observable discrepancies and workflow gaps. Credit some or all of this against a subscription.

Core product: ₹20,000–₹25,000/month.
One legal entity, a defined set of supported sources, an included transaction allowance, exception handling, evidence schedules, and close exports.

Growth product: ₹40,000–₹60,000/month.
Higher volume, additional entities or sources, stronger approval controls, and agreed integration scope.

For accounting firms and embedded partners, later introduce an annual minimum plus active-client or processing-volume tiers.

I would avoid charging a percentage of export receipts or “FX leakage.” Such pricing creates arguments about what counts as savings and can undermine neutrality.

Test the value equation rather than assuming it

Suppose a prospect has ₹2 crore in monthly foreign receipts.

An illustrative value case:

• Actionable cost improvement of 0.20% produces ₹40,000/month.
• Twenty-five hours of work avoided, valued at ₹1,000/hour, represents ₹25,000/month of capacity.
• Combined modeled value is ₹65,000/month.
• At a ₹20,000 subscription, that is 3.25 times the fee in gross modeled value.

But the sensitivity is important. At only 0.02% actionable improvement, the cost benefit falls to ₹4,000. Labor capacity is not necessarily cash savings, and some work may move rather than disappear.

Therefore, sell on measured close improvement plus verified financial benefit, not an assumed twenty-basis-point saving.

The operational SaaS test

At ₹20,000 monthly revenue and an assumed 80% gross margin, monthly gross profit is ₹16,000. An assumed ₹1.2 lakh acquisition cost implies approximately 7.5 months of gross-profit payback, before any separately excluded onboarding costs.

That model fails if every customer requires custom scripts and repeated manual bank chasing.

Track implementation labor, document review, support, FX-data costs, infrastructure, and integration maintenance in the economics. Do not hide recurring operations labor below the gross-margin line.

Where customers need a managed bank-follow-up service, price it separately or deliver it through a partner.

A valuable niche SaaS business is plausible. Venture-scale potential is not yet demonstrated.

The distinction is the number of genuinely addressable customers and the achievable annual contract value—not the total value of Indian exports.

Simple scaling arithmetic illustrates the requirement:

These are revenue scenarios, not TAM estimates or forecasts.

Public research does not establish how many Indian legal entities simultaneously have the necessary transaction complexity, accessible data, budget, and dissatisfaction with existing alternatives.

I would build an account-level serviceable-market model using those filters. Exclude overseas-parent flows outside the product’s scope, low-complexity exporters, and businesses adequately served by native tools.

The expansion sequence I would prefer

First, prove the workflow directly. Acquire a small set of similar exporters and show repeatable onboarding and retention.

Then, distribute through accounting and outsourced-finance firms. A multi-client workspace becomes attractive once the underlying workflow is stable. Position it as increasing the firm’s capacity and review quality, not simply eliminating billable work.

Then, offer embedded infrastructure. Add APIs for accounting platforms, financial-operations providers, or payment companies when several partners want the same data model and output.

Expand into D2C or another geography only after proving that most of the core system is reusable. Country-specific regulatory workflows should be separable modules.

Founder-led sales first

Start with a named list of fifty suitable businesses, not generic ads targeting “exporters.”

Seek finance teams with multiple payment sources, an upcoming audit or close, unresolved settlement differences, or document-management problems. Lead with the completed workflow:

“We reconcile a historical export period, explain the differences, and deliver an invoice-linked evidence pack. You keep your existing payment providers.”

That is more credible than “we recover hidden FX losses.”

In discovery, ask the customer to show the last actual close. Find out which files were used, which exceptions remained unresolved, who approved deductions, and what an auditor or bank subsequently requested.

Ask what they have already tried and why it was insufficient. A prospect who can solve the problem using a native report and thirty minutes of spreadsheet work is not your ideal customer.

Channel partnerships after direct proof

Work with a few CA or outsourced-CFO firms that already handle export clients. Their first role should be design partner and reviewer; their distribution value comes later.

Payment providers are potential partners, but neutrality matters. Avoid making recommendations primarily because a provider pays a referral commission.

Also, RBI’s PA-CB directions already require providers to supply relevant information/documents to the exporter’s AD bank for applicable monitoring-system closure. Your role should be to coordinate and normalize this workflow—not assume providers have no obligation or capability here. Reserve Bank of India

What constitutes a strong case study

Publish a customer-approved before-and-after comparison: close time, automatically reconciled coverage, unresolved items, evidence completeness, and verified overcharges or negotiated savings.

“Found ₹5 lakh leakage” is not persuasive unless you demonstrate what the amount represents and what actually happened afterward.

Choose the first two payment integrations from the design-partner evidence. Stripe and PayPal are plausible candidates, not mandatory choices.

Proposed acceptance criteria

I would require all of the following before materially increasing investment:

Commercial evidence: At least three of the five serious pilots convert to a recurring paid plan at a price compatible with the model.

Workflow evidence: The supported close process takes at least 50% less customer effort than the recorded baseline—not just a faster matching step.

Data evidence: Target at least 95% automatic reconciliation by value for fully ingested, supported settlement flows, while also reporting count coverage, excluded records, and unresolved evidence. Never present this as coverage of all customer activity.

Accuracy evidence: Independently review matches. Report precision separately from coverage, and allow no silent false compliance associations in the pilot acceptance sample. A small clean sample does not prove production-wide perfection.

Operational evidence: Onboarding trends below one working day of internal effort, and recurring review/support does not consume the subscription margin.

Clear reasons to stop or narrow the product

Pause the broad concept if customers will not share the necessary data, native tools adequately solve the job, apparent savings are mostly market movement or legitimate fees, or most monthly work remains bespoke bank chasing.

Also narrow the scope if reliable invoice attribution cannot be established for the selected flows. Missing source evidence is not something a better matching model can always repair.

The most credible long-term advantages are:

A trusted financial and evidence model. Every conclusion can be traced to its inputs, assumptions, allocations, and approvals.

A growing library of resolved exceptions. With appropriate customer permissions, repeated real-world cases can improve rules, document handling, and operational playbooks.

Bank- and provider-specific workflow knowledge. Effective-dated requirements, accepted evidence, and repeatable preparation—not unsupported promises of universal integration.

Distribution through finance professionals. Accountants and outsourced-finance teams can embed the product into a recurring service.

Low implementation and servicing costs. A competitor with similar features is less threatening when you can reliably onboard and support the target customer with much less effort.

Start with a small team: a founder focused on domain modeling and customer discovery, another strong integration/backend engineer, and a hands-on finance/FEMA/GST specialist. Add further engineering and sales capacity after the same product works for multiple paying customers.

Keep employer code, confidential contracts, nonpublic pricing, and customer information outside the venture. Public documentation and consented pilot data should be sufficient to validate it.

Build the evidence-backed export close, not the FX-markup widget.

The original idea contains a genuine workflow opportunity, but its strongest version is broader than FX measurement and narrower than a complete cross-border treasury platform.

I would commit first to five paid design partners, a limited set of supported payment flows, and repeated month-end closes. Those pilots should answer the questions public research cannot: whether customers will pay, whether the information is sufficiently observable, and whether the work can be delivered at SaaS margins.

My confidence is strongest in the feasibility of a constrained, well-designed product. The largest uncertainties are distribution, willingness to pay, and exception-handling costs. Resolve those before pursuing a broad API platform or a venture-scale market story.

The decisive test is whether a finance team trusts your output, finishes the close materially faster, and keeps paying after the initial FX diagnostic is over.

Product delivery playbook · November 2026–October 2027

This is the complete operational companion to the market research. It translates the product thesis into an execution plan. All dates, prices, effort estimates, funnel numbers and release targets are planning hypotheses, not verified business results. Each phase must pass its stated gate before expansion.

Working name: ExportLedger.

Vision: Every international SaaS receipt should have a traceable invoice-to-bank-to-evidence story, with explicit confidence and review status.

Positioning: Provider-neutral export receivables and month-end close software for India-incorporated SaaS and digital-service exporters. It does not move money or issue certificates.

The buyer: Founder, CFO or Head of Finance. Daily users: Finance controller, operations analyst and authorized accountant. Primary use case: Monthly close, reconciled bank credits and document evidence. North Star: Customer-approved monthly export closes completed through ExportLedger.

Three product principles:

1. Evidence before inference. Each number is observed, derived, estimated or unavailable. There is no silent invented FX markup or document association.
2. A completed close before extra features. Optimize to get one approved close pack, not to display the most graphs or integrations.
3. Trust and repeatability before growth. Roll out new providers only after their supported flows pass accuracy and operational tests.

Product release policy: Begin with a concierge-assisted diagnostic, progress to a private MVP, then private beta, paid beta, version 1 and partner scale. No money movement, hedging, fully autonomous filing, or unreviewed AI allocation in the initial roadmap.

Gate policy: A calendar date is a checkpoint, not permission to ship unsafe or unverified functionality. Carry unproven capabilities forward and label them unsupported.

First 90–120 days

• Days 1–15: Interview approximately 15–20 relevant people; obtain consented datasets; map actual close work and correct buyer. Collect invoices, payment reports, bank credits, fee agreements and remittance documents with appropriate authorization.
• Days 16–35: Deliver paid or tightly scoped manual diagnostics. Understand each mismatch before automating. Ask whether the finance lead would repeat/pay for the workflow.
• Days 36–65: Build the reusable event and allocation model, basic app and supported integrations or imports. Don't create a customer-specific script per pilot.
• Days 66–90: Run live monthly closes with current process in parallel. Validate coverage by value and count, precision, customer time, review work and support cost.
• Days 91–120: Convert serious pilots to paid recurring subscriptions or narrow the thesis. Make the commercial decision from repeat use—not enthusiasm for a demo.

Delivery assumption: Two full-time engineers, founder product/sales/design ownership and part-time finance/compliance reviewer. Adjust dates if staffed differently.

Engineering workstreams: Customer discovery weeks 1–4; data architecture weeks 3–6; imports weeks 5–8; reconciliation weeks 5–10; exception UX weeks 7–10; evidence and close pack weeks 9–12; security, QA and pilot operations from week 3 onward.

Secure tenant workspace · P0 / Medium

User sign-in; legal-entity workspace and role permissions; controlled access to connected source accounts. Acceptance: One customer's files, bank references and audit actions cannot be seen by another; sensitive keys are encrypted; access can be revoked.

Invoice and bank imports · P0 / Medium

CSV/XLSX invoices, customer identifiers, settlements and statements with column mapping, validation, duplicate recognition and import logs. Preserve raw files and source timestamps. Acceptance: A replay is idempotent, failures are visible and imported currency/minor units stay correct.

First provider integration · P0 / Large

Choose the provider from real pilot source mix. Stripe is plausible, not mandatory. Pull balances, fees and payout associations where available; clearly document unsupported cases. Acceptance: Complete pagination/backfill and account-scoped idempotency; no claim of exact conversion time without supporting data.

Canonical event model · P0 / Large

Represent invoice, payment, processor balance event, fee, conversion, payout, bank credit, source document and declaration as separate records. Use many-to-many allocation amounts, confidence and evidence. Acceptance: Partial payments, combined settlements, refunds and repeated amounts do not force one-to-one relationships.

Matching and reconciliation · P0 / Large

Deterministic identifier and amount rules first; reconcile amounts and currencies with clear rounding tolerance, unmatched residuals and reviews. Acceptance: No duplicate allocations or silently fabricated links; approved reconciliations tie to source records.

Gross-to-net and FX explanation · P0 / Medium

Separate FX movement, observed executed conversion, benchmark spread, gateway fees, taxes, bank charges, adjustments and unknown balance. Acceptance: Show timestamps/source of benchmark; do not call reference-vs-authorization gap 'hidden FX markup'.

Exception workbench · P0 / Medium

Queue by issue type and owner; identify missing reference, unexplained residual, unmatched invoice and document gaps. Acceptance: Finance reviewer can inspect, propose, approve, reject and leave a traceable note.

Document associations · P0 / Medium

Upload FIRA, FIRC, advice and related evidence as distinct document types. Allow many invoices per document and multiple documents per invoice. Acceptance: Status indicates observed document, extracted identifiers, pending validation and issuer/bank dependency; no automated 'certified' label.

Close pack export · P0 / Small

Export invoices to payments to payouts to bank, fee/FX explanations, evidence schedules and unresolved exceptions in a reviewer-approved format. Acceptance: A closed period has approver, timestamp, reconciliation coverage and source references.

Audit and approvals · P0 / Medium

Track sources, import attempts, rule versions, manual edits, approvals and report generations. Acceptance: Correct historical data through controlled adjustments, not silent mutation.

Post-MVP order

Private beta / P1: second provider selected by customer data; first accounting-system sync; recurring exception rules and better completeness monitoring.

V1 / P1–P2: expert-reviewed DGFT export-preparation integration, if authorization/access can be secured; AI-suggested document extraction after deterministic rules work; stronger workflow controls.

Scale / P2: CA firm multi-client workspace, reusable partner APIs only after demonstrated demand, separate country-specific compliance modules if economics permit.

Excluded: customer funds custody, payment initiation, FX execution, wallets, hedging, complete accounting replacement, automatic statutory certification and unreviewed AI financial decisions.

Navigation: Overview; Reconciliation; Exceptions; Evidence; Close Reports; Data Sources and Settings.

1. Overview: Period status, imported and missing sources, unsettled value, approval readiness, owned exceptions.
2. Reconciliation: Invoice amount/currency; payment IDs; fee events; executed and benchmark FX where verifiable; payout; bank credit; remainder. Any value opens the source or allocation rule.
3. Exceptions: Assigned cases, reason, confidence, proposed corrections, approvals and unresolved counts.
4. Evidence: Issuer and document type, invoice/remittance links, bank/portal acknowledgments, reviewer decision and missing evidence.
5. Close reports: Reviewer sign-off, locked output, exportable schedule, missing-source statement and audit history.
6. Data sources: Connection health, permission status, backfill/import logs, available fields, coverage matrix and data-completeness warnings.

Golden-path walkthrough: A finance controller imports invoices and settlement/bank data, reviews suggested matches, investigates residuals, attaches remittance advice, marks unresolved items and exports an approved close. The output separates bank-settled, customer-paid and compliance-evidence-complete status.

Planning funnel

These are targets, not benchmarks or guaranteed conversion probabilities.

Recruitment channels: Founder and peer introductions; LinkedIn finance controllers/CFOs; Indian SaaS founder communities; specialist CAs and outsourced CFOs. Target 25 personalized messages in first two weeks and a 50-account initial priority list. Don't optimize for untargeted waitlist count.

Personas: Founders want visibility and low distraction; controllers want trustworthy allocations and review; CFOs want financial controls and credible ROI; CAs want consistent, auditable evidence across clients.

Founder message — discovery

Hi [Name], I'm building a finance tool for Indian SaaS companies receiving international payments through providers like Stripe and PayPal. I'm researching a recurring problem: matching foreign-currency invoices to processor payouts, Indian bank deposits, deductions and remittance documents. Would you be open to a 20-minute conversation about your current monthly process? I'm learning from real workflows before building more.

Design-partner invitation

Hi [Name], thanks for showing me your export close process. We're inviting five Indian SaaS companies to a founding design-partner program. We will reconcile a defined historical period, explain supported fee and FX differences, link available remittance evidence and deliver a customer-reviewed close pack. The pilot includes assisted onboarding, weekly feedback and agreed data/confidentiality terms. Would you like to review the pilot scope and pricing?

Key discovery questions

• Show me the last close from start to sign-off. Which five files or systems did you use?
• How many hours and people were involved? What did you leave unresolved?
• When a payout differs from invoices, what is your procedure? Who makes and approves adjustments?
• Which documents are requested by your bank, CA or auditor? What arrives late?
• What Stripe, PayPal, bank or accounting reports already help? Why are they insufficient?
• Are you an Indian invoicing legal entity, an overseas parent/subsidiary, or merchant-of-record customer?
• Can you share a defined, consented historical data sample with a legal/data-handling agreement?
• What measurable improvement matters? Who approves software spend and at what range?

Founding partner package

A one-to-three-month historical diagnostic, assisted setup, weekly review, sixty-day private beta, a transparent limitations document, agreed retention/deletion and support procedures, and a conversion offer. Proposed initial diagnostic ₹25,000 one-time, creditable against a subscription; waive only for strategic partners who commit meaningful time and data.

Week 1: Data agreement, authorized import, completeness report and baseline close time. Identify legal entity, payment flow and unsupported cases.

Week 2: Review the first invoice-to-bank reconciliation. QA ambiguous matches; record every unsupported source and missing reference.

Week 3: Improve exception handling, audit trail and accounting exports. Do not patch customer records outside the product without documenting it.

Week 4: Finance reviewer signs off on the defined close pack, including unresolved amounts and evidence gaps; compare to prior process.

Following month: Run the process again with lower founder effort; evaluate whether it is a repeatable subscription need.

Release-readiness checklist:

• Three design partners have independently reviewed real reconciliation output.
• A supported invoice-to-bank flow ties out; refunds, partial payments and pooled settlements are explicitly handled or excluded.
• Monetary precision, currency conversion rules, no double allocation and balance conservation are tested.
• Raw evidence and all assumptions are traceable; every unknown is labeled.
• Regulated document terminology and rule dates reviewed by qualified specialists.
• Tenant isolation, least privilege, encryption, audit, retention and backup restore tested.
• Connector completeness, retries, backfill, duplicate detection and failure alerting work.
• Reviewer can approve, reject and export a period-level close.
• Written pilot scope, support escalation, limitations, pricing and data terms are accepted.

Public-beta readiness: Stable supported-flow matrix; documented incident response; repeatable customer setup; pricing and paid conversion; at least one consented case study; a clear support owner.

Simple value model: Monthly eligible receipts × actionable improvement rate + finance hours saved × cost per hour. Example: ₹2 crore × 20 bps = ₹40,000; 25 hours × ₹1,000 = ₹25,000; total illustrative value ₹65,000 vs ₹20,000 fee. These values are hypotheses, not promised savings. At 2 bps the cost component is ₹4,000.

Price experiments: One-time diagnostic ₹25,000; core ₹20,000–₹25,000/month; growth ₹40,000–₹60,000/month. Test the customer's willingness to pay. Prefer fixed plans and justified usage tiers over a percentage of 'leakage'. Partner pricing comes later.

Unit-economics example: ₹20,000 monthly fee × 80% assumed gross margin = ₹16,000 monthly gross profit. If assumed CAC is ₹1.2 lakh, gross-profit CAC payback ≈ 7.5 months excluding onboarding. Actual margin must include manual bank chasing, QA, data licensing and connector maintenance.

Go/no-go at day 30: 20 interviews, five datasets and three diagnostic commitments. At day 60: two real datasets reconciled and finance-reviewed. At day 90–120: three paid subscribers, measured close reduction, repeatability and tolerable service cost.

Stop or narrow if: Customers cannot supply lawful sufficient data; native reports solve most of the job; FX 'leakage' proves to be mostly timing and legitimate charges; source data cannot support reliable invoice attribution; or bespoke bank work consumes the subscription margin.

Recommended architecture: Modular monolith + PostgreSQL + durable job queue + object storage + provider-specific worker adapters + audit-event history. Add systems only when scaling data justifies it.

Events: invoice, invoice line, credit note, payment, processor balance event, fee, FX conversion, payout, bank credit, remittance document, declaration and allocation. Every event tracks tenant, legal entity, source ID, amounts/currencies, timestamps, source availability and revisions.

Allocation invariants: No double-spend of an amount; multi-currency amounts retain native precision; opening balance + movements = closing balance; pooled settlements reconcile to component events; residuals remain visible. Support many-to-many invoice/payment/document mappings.

Connector contract: Classify available fields as observed, derived, estimated or unavailable. Differentiate API event time and conversion execution time. Support backfill, pagination, idempotency and account-level completeness. Document where direct bank or statutory system access is absent.

Human control: Exact identifiers and deterministic rules first; AI suggests, never certifies, an ambiguous match. Approval and audit of adjustments are mandatory. Do not infer GST eligibility from possession of a remittance document.

Regulatory boundaries: Preserve distinct FIRA/FIRC, IRM, eBRC, EDF and EDPMS semantics. Treat bank submissions and acknowledgments separately from internal matched status. Keep rules effective-date aware and seek domain legal review. Stay read-only and non-custodial in MVP.

Launch order: Founder-led diagnosis → paid private beta → customer case study → small targeted public beta → repeatable self-service supported flows → CA/outsource-CFO partner trials → embedded API only on repeated partner demand.

First website conversion: "Book an export reconciliation diagnostic." Secondary: "Apply for founding beta." Avoid broad launches until a customer-approved case study exists.

Customer case study template: Baseline close time vs after; supported matched amount by value/count; remaining exceptions; evidence completeness; verified overcharges actually recovered or addressed. Do not conflate all reference-value differences with savings.

Initial roles: Founder owns product, sales and roadmap; backend engineer owns ingestion, schema, correctness; full-stack engineer owns workflow and reports; finance/FEMA/GST domain reviewer validates legal terminology; security/legal advisors review access and contracts.

Weekly cadence: Monday priorities; concise engineering sync; Wednesday customer feedback; Friday demo and metric review. Monthly go/no-go against product, financial and reliability gates.

Immediate first 14 days: Draft one-page charter; research 50 prospects; contact first 25; interview 8–10; secure 2–3 consented datasets; deliver the first human-reviewed gross-to-net diagnostic. Prioritize real source records over polished mockups.

Longer term: Prove independent direct customers first; then automate repeated exception patterns; then distribute through accountants; then consider partner APIs and a separate goods-export workflow. Build competitive advantage through correctness, source provenance, proven support efficiency and workflow embedding.

Final product discipline: Five design partners. Three paying customers. One repeatable, reviewed monthly export close. The journey becomes a scalable SaaS business only if those numbers are real and repeatable.