Companion to the Detailed Scope
Questions for Client
Open items we'd like to confirm before finalising scope and cost
The following questions came up while preparing the detailed scope. Your answers will help us lock down the final feature list, remove ambiguity, and adjust effort or cost where needed.
What does Tally not cover in your invoicing and transactions workflow today?
Tally already handles invoice issuance, GST, ledgers, and payment recording. Before we build Invoicing and Transactions modules in the platform, we want to be clear about the gap they fill.
Our reading is that the missing piece is mapping invoices and payments to specific projects (and companies) - something Tally has no concept of. If that is the only gap, the platform's role becomes much narrower: track which Tally invoice belongs to which project, and which payments have settled it.
If that's accurate, we'd recommend collapsing Invoicing and Transactions into a single "Payments & Invoices" module - both are just financial events linked to a project or company, and separating them creates duplicate data entry and unclear boundaries for staff.
What we need from you: confirmation that project-to-finance mapping is the main gap - or a list of other things Tally doesn't do for you that we should plan for.
Will invoices and transactions be entered into the platform manually, or synced from Tally?
This is a significant scope decision. Manual entry is straightforward but means staff record every invoice and payment twice - once in Tally, once in the platform. Sync from Tally avoids the double entry but requires an integration layer.
Tally exposes an XML-over-HTTP interface that can be used to read and write data, but a few practical constraints apply. To scope this properly we'd need to know:
- Which edition of Tally is in use - Tally Prime (desktop), Tally on Cloud, or Tally Server?
- Is the machine running Tally always on, and is it acceptable to expose it (via a sync agent or tunnel) for the platform to reach?
- Who owns the data day-to-day - operations staff (who'd use the platform) or the accountant (who lives in Tally)?
Option A - Manual entry only
- Staff enter invoice number, amount, project link in the platform
- Low technical risk, no dependency on Tally setup
- Double entry; risk of drift between Tally and platform
Option B - Tally sync (one-way read)
- Platform pulls invoices and payments from Tally automatically
- Staff only need to tag each invoice/payment with a project
- Additional scope and cost; depends on Tally setup feasibility
What we need from you: your preferred direction, and answers to the three questions above so we can confirm feasibility before quoting the integration.
Should the platform generate invoices, or only track invoices issued from Tally?
We understand Consultway already uses Tally for invoicing, GST filings, and accounting. If Tally remains the system of record for invoices, building a parallel invoice generator inside the platform creates duplication: two PDFs, two invoice numbers, and the need to reconcile between them.
Our recommendation is to scope the Invoicing module as tracking-only - staff record the Tally-issued invoice number, amount, date, GST breakup, and link it to the relevant project and company. The platform handles linkage and reporting; Tally continues to issue the actual invoice document.
Option A - Tracking only (recommended)
- Manual entry of invoice number, date, amount, GST, party
- Linked to project, company, and transactions
- Status tracking: Sent, Paid, Partially Paid, Overdue
- Optional upload of the Tally-generated PDF for reference
- Lower scope and cost; no template design
Option B - Generation + tracking
- Full invoice creation with line items, GST breakdown, PDF export
- Auto-numbering with manual override for Tally-issued invoices
- Invoice template designed to match Consultway's existing format
- Risk of duplication with Tally; double entry or unclear authority
What we need from you: confirmation of Option A or B. If A, we'll revise Module 8 and the cost breakdown to reflect the reduced scope.