Billing and Fee Collection for Architecture Practices

Here's an uncomfortable pattern I keep seeing in Indian architecture practices: brilliant work, respectable fees on paper, and a receivables list that would make a bank nervous. The design got delivered months ago, the invoice went out weeks late, and the payment is now a monthly phone call that the principal personally makes, because apparently a master's degree in architecture qualifies you to be your own collections department. Billing and fee collection is the least designed part of most practices, so let me treat it like a design problem: structure, then process, then tooling.

Structure: get the fee agreement right before the first drawing

Collection problems are usually contract problems wearing a disguise. Before process and software can help, the fee structure itself needs three properties.

Stage-linked, not time-linked. The classic structure works: a percentage or lump sum split across concept, design development, tender documentation and construction phase, with each tranche payable on stage completion. The critical detail is defining completion by deliverable ("issue of the design development set") rather than by feel, because a stage that completes on a drawing issue is a stage nobody can dispute. Notice what that implies: your billing triggers are drawing-management events, which is one more reason working drawings management and billing belong in the same system.

Front-loaded enough to survive. Practices habitually under-weight early stages, then carry the client's project on their own payroll. The thinking work is front-loaded, the fee should lean that way too, and a meaningful signing advance is non-negotiable, it's the client's skin in the game.

Explicit about scope creep. Revisions beyond an agreed count, additions in scope, extended construction periods, each needs a named price in the agreement. Not because you'll always charge it, but because a written rate turns an awkward conversation into a line item. The pattern of documenting decisions as they happen, which I covered from the query side in managing RFIs on architecture projects, applies just as much to scope and fees.

The billing rhythm: invoice on the event, not the month

Now process. The single highest-impact change a practice can make is this: the invoice goes out the same day the stage completes. Not at month-end, not when someone remembers, the same day. Two reasons. Psychologically, the client just received the deliverable and the value is vivid, an invoice landing that day gets processed, while one landing five weeks later gets scrutinised. Mechanically, same-day billing only happens when raising an invoice takes minutes, which is a tooling question we'll get to.

Here's the rhythm I recommend, end to end:

The GST layer sits under all of this. Architectural services attract 18% GST under SAC 9983, your invoices need the correct CGST/SGST or IGST treatment depending on place of supply, sequential numbering, GSTIN, the works, and corporate and builder clients will bounce anything sloppy because their input credit depends on it. Hand-building this in Word is where both the delays and the errors come from, the same disease I diagnosed in why spreadsheets are quietly costing you margin.

Collection: make paying easier than delaying

Fee collection in India has a truth nobody says plainly: a lot of "delayed" payments are really "inconvenient" payments. The invoice PDF asks for a NEFT to an account number, the client's accountant needs three approvals to run it, and your fee waits in someone's to-do pile. Put a Razorpay payment link on the invoice and suddenly the decision-maker can pay from their phone during the call where you remind them. Practices that attach payment links see the lag shrink dramatically, and the awkward follow-up call often becomes unnecessary.

The second collection lever is visibility. When the client has watched the project move, deliverables issued, site progressing, everything documented, the invoice arrives as a receipt for visible value instead of a surprise. That's part of the quiet financial case for running the whole practice, drawings, site, approvals, billing, on one connected timeline, the way I sketched in the complete interior project checklist for the interiors side of the house.

What this looks like when it's tooled properly

Let me describe the practice-level end state, because it's very achievable. The fee schedule for every project lives in the system, stage by stage. When a stage completes, someone clicks once, and out goes a compliant GST invoice, correct tax split, SAC code, unbroken number series, with a Razorpay link on it. The payment reconciles against the invoice automatically, the org-wide transactions ledger updates, budget vs actuals stays current, and everything syncs to Tally or Zoho Books so the accountant works where they already work, no re-typing, no month-end reconciliation marathon.

That's not an enterprise fantasy, that's just what happens when billing lives in the same workspace as the projects. It's exactly how Designa is built, and it's priced for Indian practices: one flat founding price for the whole studio, billed in rupees, no per-seat math, with unlimited free client logins so every client can see their invoices and pay online. Professional bodies have long pushed for dignified fee practices, the Council of Architecture has historically published fee guidance for architects, and communities like the Institute of Indian Interior Designers keep the conversation alive on the interiors side, but guidance only becomes cash flow when your own billing machinery is fast and clean. For practices in high-velocity markets, my Mumbai architecture software guide adds the metro-specific view.

Your fees fund everything else the practice does, so give collection the same rigour you give a drawing set. If you want to see stage billing, GST invoicing, payment links and the ledger running on one timeline, walk through demo.designa.work, and the founding offer is at go.designa.work.