The spreadsheet is doing three jobs it should not
In a lot of Kerala and wider-India SMEs the custom screen is not the system of record. Tally is, or the bank is, or the SMS log the customer believes. The spreadsheet in the middle exists because those three do not talk. Someone downloads a settlement file, types a receipt, copies a mobile number, and messages the branch that the bill is in. The job of an integration is to remove that retype — not to add a fourth login that staff will ignore.
Three connectors show up in almost every operations brief we see: payments in, SMS out, Tally as the book. Each is an API conversation with rules, errors, and a person who must own the mismatch. Treat them as “we will integrate later” and you have scheduled the spreadsheet to survive go-live. Treat them as one vague “integrations” line and you cannot tell which connector stalled the project.
This is ordinary business process automation: software moving facts you already have, according to rules you can write down. It is not a new platform. It is three contracts, three failure modes, and one named owner for the queue when a webhook is late on a Saturday.
Payments: the money arrived, but where?
A payment gateway will take a card or a UPI intent and tell you, eventually, whether the money moved. The useful integration is not the checkout button. It is the path from “paid” to the order, the receipt, and the ledger. If that path is a CSV someone fetches on Monday, you still have the spreadsheet. If that path is a webhook your .NET service verifies, idempotently stores, and posts onward, you have a connector.
What breaks: duplicate webhooks, events that arrive before your order row exists, refunds that never hit the original receipt, settlements that batch twenty payments into one bank line, and test keys left in production. What also breaks is assuming “success” on the redirect page is the truth. The truth is the signed event, stored with the gateway’s id so you never post twice.
Who owns reconciling: finance. Not the developer on call, except to explain a missing event. Write a Tuesday job: unmatched payments older than one day appear on a list. Someone in accounts marks them, or the system matches them when the late event arrives. If that list has no owner, you will discover the gap at GST time, which is the expensive way to learn.
Do not start with every method the gateway offers. Start with the method your customers already use, one currency, one company. Capture the gateway reference on the order. Show it to the person who answers “did my payment go through?”. Export it in the file accounts already know. That is enough to retire the first sheet. Cards-plus-net-banking-plus-wallets-plus-subscriptions is how a two-week connector becomes a quarter.
SMS: the customer already believes the phone
Transactional SMS in India is not a string you POST to a vendor. It is a DLT-registered template, a sender id, a purpose, and a trail. Promotional and transactional are different roads. Mixing them is how you get filtered, or worse, blocked, while the warehouse still thinks the dispatch note went out. The integration is: an event in your system (packed, paid, OTP) maps to one approved template, with the variables you actually registered, and a log of the provider’s id and the final state.
What breaks: a template that does not match the registered text, a variable that is too long, a number still on a DND preference for that category, a vendor balance that hit zero on a festival Saturday, and retries that send the same OTP four times. What also breaks is using SMS as the system of record. The phone is a notification. The dispatch still has to exist in your database. If the only proof is a screenshot in WhatsApp, you have not integrated. You have added a cost to the old process.
Who owns reconciling: operations for “did the customer get the message”, and a named admin for DLT and vendor balance. Those are different people. The first looks at a failed-send queue the morning after a dispatch run. The second renews templates and pays the vendor. If both jobs sit with “IT”, templates expire and nobody notices until Onam weekend. Write the two names on the brief.
OTP and dispatch-ready are good first templates. Marketing blasts are not a first connector. If the business still lives in a WhatsApp group, SMS will not replace the group on day one. It can replace the “please tell the customer we packed it” ping that currently interrupts the supervisor. Measure that ping. Then decide whether a second template is worth the DLT wait.
Tally: the book still wins arguments
For many of the businesses we sit with, Tally is not “legacy”. It is the legal book. The custom system can be the operational front — orders, jobs, stock movements — and still post into Tally, or export a voucher file someone already trusts. Ripping out the books on day one is how implementations fail. The integration is the posting rule: which voucher type, which ledgers, which tax, which company, and what you do when Tally has the company open and locked.
What breaks: ledgers that do not exist yet, GST treatments that three people describe three ways, item names that do not match the Tally stock item, a company file that is open on a desktop so the API waits, and a “success” that posted to the wrong year. What also breaks is posting every keystroke. Post on a defined event — invoice confirmed, receipt matched — and keep a log of the voucher number Tally returned. That number is how finance proves the two systems are the same fact.
Who owns reconciling: the accounts lead, with a parallel-run window. Nightly or on-post, the custom system and Tally must agree on a list of fields you wrote down. Mismatches are a queue, not a feeling. If Tally remains the book, the custom screen is wrong when they disagree — until someone decides a voucher was posted twice and voids it through a process, not a delete. Developers do not decide GST. They implement the rule accounts signed.
A first slice often leaves Tally in place and only posts sales vouchers for one location, or only exports receipts. That is enough to retire the retype of those rows. Opening stock, purchase, payroll, and last year’s cleanup can wait. If a vendor promises “full Tally replacement in the first month”, ask who will sign the books. The answer is usually silence. Silence is your cue to shrink the connector.
What the three connectors share
Each connector is a contract: authentication, an idempotency key, a retry policy, and a visible error. Each needs a log a human can open on Thursday. Each needs a queue of exceptions that is not a developer’s inbox. The API is the menu. The work is what happens when the kitchen sends the wrong plate, or no plate, or two plates.
| Connector | Typical break | Who owns the queue |
|---|---|---|
| Payments | Duplicate or late webhook; refund unmatched | Finance, unmatched-payments list |
| SMS | Template mismatch; vendor balance; DND | Ops for delivery; admin for DLT |
| Tally | Locked company; ledger or GST mismatch | Accounts lead, parallel run |
If you cannot fill the third column with names, do not build the connector yet. Unowned automations get switched off the first time they do something surprising. That sentence is the whole of useful automation. The spreadsheet survives because it has an owner — the person who currently hates it. The integration must inherit that owner, not replace them with a Slack channel named “dev-alerts”.
A first slice that actually removes a sheet
Pick one path that currently requires the spreadsheet. Example: customer pays on a link, you send a template SMS, a receipt voucher lands in Tally. Write the definition of done as those three facts on one order, with a log, with an unmatched list. Host it. Run it beside the old sheet until finance will sign. Then stop using the sheet for that path. Do not add purchase, payroll, and a second gateway in the same slice.
Week one is access: sandbox keys, a test Tally company, DLT templates that already exist or a honest wait if they do not. Week two is the happy path on real (or production-like) records. Week three is the exceptions you already know: failed pay, refund, SMS rejected, Tally locked. Week four is the parallel run and the handover of the queues. If a vendor needs a quarter to “set up the integration layer” before those four weeks, you are buying a platform. Ask why the existing systems cannot hold the work.
We implement this as a small ASP.NET service that already knows how to call HTTP APIs, verify signatures, and write an audit row. That is .NET development, estimated like a feature with three external contracts, not like a transformation. The screens can be ugly. The log cannot be. The owner cannot be “we”.
When not to integrate
If the volume is ten rows a week and the person who types them will still check every one, a connector may not pay back. If nobody can write the posting rule, you have a process project, not an API project. If Tally is used as a drawer of unmanaged companies and personal files, you will encode a mess. If the payment vendor cannot give you a webhook you can verify, you will stay on the CSV — say so, and price the manual step, rather than pretending the button is the integration.
WhatsApp-as-API is a separate decision. If the business will not leave the group, you can still post to Tally and still match payments. Do not hold the book hostage to a chat migration. Do not hold SMS hostage to a WhatsApp Business approval that has no date. Sequence the connector that removes the most retype first. That is usually receipts or dispatch notices, not a new channel.
The briefing we want, and the one we send back
Write: which of the three you need in the first slice; which system is the book; who owns unmatched money, failed SMS, and Tally mismatches; how many events a week; whether DLT templates already exist; whether a test company exists; what the spreadsheet currently columns. Attach one redacted settlement file and one voucher. That is enough to say yes, not yet, or “Tally first, SMS later”.
We will send back assumptions: webhook verification, idempotency, which voucher type, which template ids, retry windows, and the names on the queues. If those names are blank, we will not start the build. We will start the conversation about who sits with exceptions after go-live. That conversation is cheaper than a connector that posts twice on a festival Saturday and has nobody to call but the person who wrote the code.
Three connectors, three queues, one fewer spreadsheet. That is the project. Everything else — a portal, a second branch, an app — can wait until the receipt, the message, and the voucher are the same fact, and someone in the business can prove it without opening Excel. If you cannot prove it, you do not have an integration. You have a demo that will stall the next time the gateway retries.