Most accounting packages in Nepal were not built to be integrated with. How to pick a direction, what the integration really looks like, and what breaks in month three.
Key Takeaways
- Most accounting packages in Nepal were not built to be integrated with.
- How to pick a direction, what the integration really looks like, and what breaks in month three.
The short answer
Most accounting software in common use in Nepal was not designed to be integrated with. There is usually no clean API waiting for you. What exists is file import, an ODBC connection, an XML interface, or a folder someone drops a CSV into, and the quality of your integration depends entirely on which of those you get.
Find out which one before anyone quotes on the work, because the answer changes the estimate by a factor of three.
Decide which system is the truth
This is the whole design, and it has to be settled before code is written. Either sales originate in your application and flow into accounts, or they originate in accounts and your application reads from them. What cannot happen is both editing the same thing.
Two-way sync between a custom system and a desktop accounts package is where these projects go to die. You get a conflict, nobody has defined who wins, and the two systems disagree about the same invoice for a week before anyone notices. Pick a direction and keep it.
What the integration actually looks like
The good case
The accounts package exposes an interface you can write to, running on a machine your software can reach. You push journal entries or invoices on a schedule, log every push, and reconcile counts daily. Boring and reliable.
The common case
You export a file in the format the package expects, on a schedule, and someone imports it. Less elegant and perfectly workable, as long as the export is deterministic and you keep a copy of everything sent. The failure mode is a double import, so every batch needs an identifier the importer can refuse twice.
The bad case
The accounts software runs on one machine under someone's desk, has no interface, and the only path is a person retyping. That is not an integration, and the honest advice is to fix the accounting side first rather than build software around a dead end.
Things that break in month three
- The chart of accounts changes. Someone adds a ledger and your mapping silently drops transactions into the wrong place. Map by code, not by name, and alarm on an unmapped code rather than defaulting it.
- The fiscal year rolls over. Nepali accounting runs on Bikram Sambat. If your system thinks in Gregorian, year-end is where the two disagree. Our note on handling BS dates covers the general trap.
- A voided invoice. Your system voids it; accounts already has it. Decide whether that becomes a credit note or a deletion, in advance, in writing.
- Rounding. Two systems rounding differently produce a one-rupee gap that compounds into a reconciliation nobody can close.
Keep the boundary narrow
Send the smallest thing that satisfies the accountant, which is usually summarised journal entries rather than every line of every transaction. Pushing full detail into accounts makes both systems harder to reason about and gives you more to reconcile when they disagree.
Your application can keep the detail. Accounts needs the totals. If you are scoping this kind of boundary, our custom software work covers how we usually draw it.
Frequently asked questions
Can my custom software talk to Tally?
Usually yes, through its XML interface, and the practical constraint is that it has to be running and reachable. A desktop install on a machine that gets switched off at night is the thing that breaks the schedule.
What about Swastik or other local packages?
Varies by package and version. Ask the vendor directly what import or interface options exist, and get the answer before you plan the integration rather than after.
Should data flow both ways?
Rarely. One direction, clearly defined, with one system owning each fact. Two-way sync looks flexible and produces conflicts nobody has rules for.
How often should it sync?
Daily is enough for most businesses and much easier to reconcile than real time. If something fails you have one batch to inspect rather than four hundred individual events.
Who fixes it when the numbers disagree?
Decide this before launch and write the name down. An integration with no owner is discovered to be broken at year-end, which is the most expensive possible moment.
Enjoyed this article? Share it with others!
Written by
Antbytelabs
Writing about the software we build at Antbytelabs in Bhaktapur, Nepal.