Building a Financial Operations Console for MSME Businesses

Most B2B SaaS for small businesses fails the same way: it treats the business owner like an analyst when they actually need an executor.

This client served MSMEs - small and medium enterprises in India - whose founders were running operations, sales, finance, and customer service from a phone. The pitch wasn't "better dashboards." It was "stop opening seven tabs."

Context

MSMEs run their finances out of fragments - a CRM holds the customer relationship, a payment gateway holds invoice settlements, an accounting tool holds the books, WhatsApp holds the actual back-and-forth with the buyer about when payment is coming. There is no single screen where a founder can see "how much do my customers owe me, when are they paying, and what do I owe my vendors this week."

The console's job was to be that single screen.

The product challenge

The hard part was that the existing data lived in tools the customer didn't want to abandon. The CRM was where the sales rep already worked. The payment gateway was where invoices were already issued. The accounting tool was already wired to the chartered accountant's process. Asking the customer to rip and replace any of these would have killed the deal.

So the console couldn't be a system of record. It had to be a system of display, with two-way sync where it mattered, and a synthesized state model that reconciled across sources where the underlying tools disagreed.

My role

I led product and engineering execution: integration architecture across CRM, payment gateway, and bank rails; the unified financial state model; the operations console; the reconciliation workflow; permissions; audit trail; and ongoing customer onboarding.

Core features

• Receivables view: every outstanding invoice across CRM and payment systems, sorted by aging, with the buyer relationship attached.
• Payouts view: every payable, scheduled and overdue, with vendor relationship attached.
• Reconciliation workflow: when CRM and payment data disagree, the console flagged and let an operator resolve, with the resolution tracked.
• CRM sync: bidirectional updates so the sales rep working in their existing CRM saw the financial status without switching tabs.
• Status mapping: translation layer between vendor-specific status codes and a unified internal vocabulary.
• Audit trail: every state transition logged with actor, source system, and reason. Auditable end-to-end.
• Role-based permissions: owner, finance, sales, view-only - applied to both the console and the underlying integrations.

Technical highlights

The integration layer was the platform's spine. Every integrated system had its own webhook contract, its own polling fallback, its own quirks around rate limits and idempotency. We standardized on an event-ingest pipeline - every external update became an internal event, normalized to one schema, and then projected into views.

This decoupling meant that adding a new CRM or payment provider was a connector exercise, not a re-architecture exercise. Customers who insisted on their specific accounting tool got an integration in days, not quarters.

The unified financial state model was the second hard piece. CRM, payment gateway, and bank statements report the same underlying transaction with different lifecycle vocabulary. We built a deterministic mapping - sourced from operator input, refined over time - that turned vendor terminology into one internal vocabulary. The console showed the unified state; "underneath," the operator could click any row and see the source-system state per integration.

Reconciliation was treated as a workflow, not a job. When sources disagreed, the console flagged the conflict, surfaced the evidence (timestamped events from each source), and let a human operator resolve. The resolution itself became an event, fed back into the state model.

What this taught me

MSME software has a usability gravity. The customer is the operator and the executive. Every extra click is paid for in a context they don't have time to acquire. The product has to assume the user is intelligent and busy - not stupid, not patient. UI conventions that feel "too simple" for SaaS are actually correct here.

Integrations are the product. The dashboards were table stakes. What customers paid for was that their existing tools talked to each other through this console. We were never going to win on dashboards alone. We won when we eliminated the tab switching.

Audit trails are a sales feature. The chartered accountants reviewing the customer's books at quarter-end were the silent procurement gatekeepers. A console with full audit-grade evidence cleared their objections in one demo. Without audit trails, every install required a separate trust-building cycle.

Outcome

The console replaced spreadsheets and tab juggling with a single view. Customers reported faster collection cycles because the receivables view made aging visible to the people empowered to act on it. Cash-flow visibility moved from "month-end surprise" to "Tuesday morning glance." The audit-trail layer cleared the accountant-driven trust hurdle that had been the longest part of the sales cycle.

---

If you are building B2B SaaS for owners who don't have time to learn it: do not start with the dashboard. Start with the question they ask their phone every morning. Make the answer one screen.