Does Your Housing Society Actually Have a Purchase Process, or Just Tally and a Prayer?

31

Large housing societies in India spend crores of rupees every year on maintenance, repairs, equipment, and vendor services. But ask how that money actually gets approved and tracked, and the answer usually involves some combination of a WhatsApp group, printed forms, the accountant’s Tally installation on a desktop computer that nobody else can operate, and someone physically walking up and down four floors to get signatures for payments

That is not a process. That is organised chaos with a spreadsheet on top.

There is a better way, and it has a name. It is called the Purchase-to-Pay process, or P2P for short. It sounds corporate, but once you understand what it actually does for a residential community, you will wonder how your society ever managed without it.

Does Every Housing Society Really Need a Full Purchase-to-Pay Process?

Honest answer? Not every society needs the entire five-step cycle from day one. A 40-unit society where everybody knows everybody, the treasurer lives in Block A and the estate manager just needs approval for a mop and a bucket of phenyl, probably does not need four levels of purchase approvals. That would be like using a crane to park a scooter.

But here is where it changes.

The moment your community crosses a few hundred units, the moment you have a professional estate manager handling expenses, the moment your annual maintenance budget runs into crores of rupees, and the moment you have multiple MC members who are busy working professionals with their own lives to manage, you need a system. 

Not because anyone is dishonest. But because informal processes break down at scale, and when they break down in a large community, the consequences are expensive, messy, and sometimes irreversible.

A 50-unit society spending two lakh a year has low complexity. A 1,000-unit community spending two crore a year with multiple vendors, ongoing AMCs, capital expenditure decisions, and an annual audit is an entirely different animal.

Is Tally Enough for Managing Housing Society Accounts?

This is the question most communities never actually ask, because Tally has been around forever and everyone just assumes it must be fine.

Here is the problem. Tally is an accounting tool built for businesses, and it works very well in that context for a very specific reason. In a business, the accountant’s boss is typically someone who understands finance deeply. A CFO. A Finance Manager. A senior accountant who has spent years in the profession. Someone who can open Tally themselves, spot an inconsistency, question a journal entry, and hold the accountant accountable because they speak the same language. The oversight works because the person doing the oversight is qualified to do it.

In a housing society, this chain breaks completely.

The society accountant reports to the Treasurer. And the Treasurer, in the vast majority of cases, is not a finance professional. She is an IT professional, or a retired government officer, or a business owner who got elected to the MC because nobody else raised their hand at the AGM. She is almost certainly a capable, well-intentioned person. But she has never operated Tally in her life and would not know where to begin if she wanted to verify whether an entry in the books, maintained in Tally, was correct.

So what happens? The accountant operates in an environment where the person responsible for oversight has no practical ability to exercise that oversight. There is no superior who can open the software and check the work. The only visibility the Treasurer gets is what the accountant chooses to present, in whatever format the accountant chooses to present it, at whatever frequency they are asked to present it.

This is not a flaw in the accountant’s character. It is a structural problem. When someone operates without meaningful oversight, not because anyone is watching for dishonesty, but simply because the tools make oversight impossible, even the most honest and capable professional gradually becomes less careful. Entries get posted without proper documentation because nobody can check. Reconciliation gets pushed to quarter-end or year-end because there is no dashboard anyone else can see. Supporting documents go unfiled because the effort of proper record-keeping feels unnecessary when the system has no transparency requirements built in.

What can the Treasurer see without asking the accountant?

How much has been spent under a specific expense head this month	No. Accountant generates a ledger report, shares it in Excel or PDF.	Yes. Budget utilisation by expense head is visible in real time.
Which expenses are pending approval right now	No. No concept of pending approvals in Tally. These live in WhatsApp or email.	Yes. All pending Purchase Requests visible with full details and one-tap approval.
Whether a vendor has been paid or payment is still outstanding	Depends. Accountant needs to pull the vendor ledger and share it.	Yes. Vendor payment status visible at any time without asking anyone.
Whether income collection is on track vs last month	No. Requires the accountant to run a collection report from Tally.	Yes. Collection dashboard shows dues raised, collected, and outstanding in real time.
Complete expense history for audit preparation	Partial. Accountant can generate reports, but supporting documents are scattered elsewhere.	Yes. Every expense has its PR, approval trail, invoice, and payment linked in one place.
Whether a specific large expense was approved and by whom	No. Approvals are not tracked in Tally. Check WhatsApp or emails to reconstruct.	Yes. Full approval trail with timestamps visible against every transaction.

Can Lack of Financial Visibility Actually Lead to Misappropriation?

Let’s talk about this plainly, because too many communities discover this problem only after the damage is done.

The Misappropriation Risk Map: Five gaps where financial risk enters in a manual process

The uncomfortable truth about Tally in a society context is not that accountants are dishonest. Most are not. The uncomfortable truth is that when people know nobody is watching, even the most diligent and trustworthy professionals gradually become lax. It is human nature. If as an accountant you know that every entry you make will be reviewed by an MC member who can log in and check the books at any time, you are careful. If you know that nobody outside your own computer can see what you have entered, and the only time anyone looks is when you generate the quarterly report yourself, the natural human tendency is to cut corners. Not necessarily to steal, but to not bother with proper documentation and notes, to process a payment without linking it to the correct expense head, to leave reconciliation for later, to skip some transactions because it adds extra steps.

Now add a structured purchase process to that picture, or rather, the absence of one. 

• No formal Purchase Request means there is no official record of who asked for an expense before it was incurred. 
• No Purchase Order means there is no document confirming what price and scope were agreed with the vendor. 
• No GR/SR confirmation means payment can go out before anyone officially verified the work was done. 

And all of this sits inside Tally on the accountant’s computer, visible to nobody else in real time.

This is not a theoretical risk. Communities across India have discovered, usually during audits or during committee transitions, that vendor payments were made without corresponding work, that the same invoice was processed twice, that expense amounts in Tally did not match the original vendor quotations, or simply that years of records were incomplete because the accountant who maintained them has since left. By the time anyone finds out, the money is long gone and the paper trail either does not exist or points nowhere useful.

The P2P process on a modern platform closes these gaps structurally. 

Every expense has a documented origin, an approval trail, a verification step, and a linked payment record. But more importantly, all of this is visible in real time to the people responsible for governance, without them needing to ask anyone for a report.

Why Is Real-Time Online Visibility Non-Negotiable for Society Accounts?

Think about how every other important financial platform in your life works today. Your bank account: you open the app and see every transaction from the last many years in two seconds. Your mutual funds: real-time NAV, transaction history, portfolio value, all on your phone. Your credit card: every charge visible the moment it is posted, with a notification before you have even put your card back in your wallet.

Now think about how most housing society accounts work. The Treasurer gets a report once a quarter that too many times after followups, generated by the accountant from Tally, formatted in Excel, shared over email. If the Treasurer wants to check something in between, she calls the accountant and waits for him to be available. If a resident asks a question at the AGM that was not covered in the prepared report, the answer is “we will check and get back to you.”

We are living in 2026. Every SaaS product that manages any kind of money, from a small startup’s expense tracking to a large enterprise’s procurement system, gives real-time visibility to everyone with the appropriate access level. This is not a premium feature anymore. It is the basic expectation of anyone who has used any modern software in any context.

Housing society accounting is the one domain where this expectation has not caught up with reality, and the reason is simply that legacy tools like Tally were entrenched before the expectation formed. But the money being managed is not the company’s money. It is residents’ money. Maintenance contributions, sinking fund, corpus fund. Hundreds of families contributing every month with the reasonable expectation that it is being managed transparently. The MC members who oversee this are doing so as elected representatives. They have a fiduciary responsibility that they simply cannot fulfil without real-time visibility into what is being spent, what is being collected, and what is sitting in the bank right now.

When ADDA’s P2P workflow is in place, any MC member with appropriate access can log in to the system at eleven at night and see 

• the current bank balance, 
• the pending payments, 
• the approved PRs waiting to become POs, and 
• the expenses that went out this week. 

No dependency on the accountant. No waiting for a report. Just the actual financial state of the community, available to the people responsible for it, whenever they need it.

What Are the Five Steps of the Purchase-to-Pay Process?

Step 1: What Is a Purchase Request and Why Does It Exist?

The Purchase Request, or PR, is where everything starts. The estate manager raises it in the system, documenting what needs to be purchased, why it is needed, how much it is expected to cost, and which budget head it falls under. 

The PR then goes to designated approvers along with full budget context. The approver can see how much was allocated for that expense category this year, how much has already been spent, and how much is remaining. So when the Treasurer is approving a repair request, she is not just asking whether the expense is necessary, but also whether the community actually has budget room for it right now. That is a completely different quality of decision compared to “the accountant says we can afford it.”

Without a PR system, what typically happens is that a vendor call leads to a verbal go-ahead, which leads to work starting, which leads to an invoice appearing on the Treasurer’s desk three weeks later with no paper trail showing who asked for it, who evaluated the vendor, or whether it was within any budget at all.

Step 2: What Is a Purchase Order and How Is It Different from a Purchase Request?

The Purchase Request is an internal document asking for permission to spend money. The Purchase Order is an external document telling the vendor what has been agreed and making it official. The PO includes the scope of work, the agreed price, payment terms, and delivery timeline. It has legal standing. If a vendor later claims they quoted something different or delivered something different, the PO is what protects the community.

In ADDA, the PO can be automatically generated from the PR data once approvals are completed. It can also go through its own approval workflow before being sent to the vendor, which is particularly useful for large expenses where a second checkpoint is good governance rather than unnecessary bureaucracy.

Many communities skip the PO entirely, going straight from “we approved this expense” to “work started.” For very small purchases, fine. For anything significant, especially AMC contracts, infrastructure repairs, or large equipment purchases, the absence of a proper PO is an open invitation to disputes and overcharging.

Step 3: What Is a Goods Received Note or Service Received Note, and Why Does It Matter?

This is the most frequently skipped step, and it is the one that causes the most financial damage when missing.

The GRN or SRN is the official confirmation that what the vendor promised was actually delivered or completed before payment is released. Think of it like checking your Swiggy order before rating the delivery, except here the stakes are a few lakhs rather than a biryani. Without this confirmation, payments can go out for work that was partially done, poorly done, or in some cases not done at all.

With ADDA’s GR/SR recording, the process simply does not move to payment until someone has confirmed the work is done. One small step, significant financial protection.

Step 4: What Is Invoice Posting and Why Should It Be Linked to the Purchase Request?

Once the GRN or SRN is recorded, the vendor’s invoice is uploaded and linked directly to the original Purchase Request and Purchase Order. The invoice amount can be verified against the PO. If there is a discrepancy, it shows up immediately rather than being discovered months later during the audit.

In communities using Tally without a structured procurement process, invoices get entered into the accounts as standalone entries with no connection to the original request or approval. By the time auditors ask questions, connecting the invoice to the original decision becomes a manual reconstruction exercise.

Step 5: What Happens at the Payment Stage?

For larger expenses, ADDA allows a separate payment approval stage before funds are released, giving the person who controls the finances one final checkpoint before money goes out. Once payment is posted, the complete record from Purchase Request to Payment sits in one place, permanently accessible, fully traceable, and audit-ready from day one. 

No accountant dependency. Just a transparent record that anyone with the right access can pull up in seconds.

How Much Time Does a Proper P2P Process Actually Save?

Let’s put some numbers to this, because “saves a lot of time” sounds nice and proves nothing.

A typical expense transaction in a large community running on manual processes and Tally looks something like this. 

• The estate manager spends 30 to 40 minutes preparing the paperwork and collecting vendor quotations. 
• He then spends one to three days chasing MC members for approvals, depending on their availability and whether anyone is travelling. 
• Each committee member spends 15 to 20 minutes reviewing documents when they finally sit down to look, and if there are four approvers, that is 60 to 80 minutes of committee time spread across multiple days. 
• Preparing and sending the PO manually takes another 20 to 30 minutes. 
• After work completion, the invoice gets entered into Tally separately with no link to the original request, adding another 15 to 20 minutes. 

By the time everything is done, a single expense transaction has consumed somewhere between 3 and 5 hours of combined staff and committee time, spread across several days.

With ADDA’s P2P workflow, 

• the PR creation takes about 10 to 15 minutes. 
• Approvals happen within hours because committee members approve from their phones. 
• The PO is almost completely auto-generated. 
• Invoice linking takes under 5 minutes. 
• The entire transaction can be completed in 1-3 hours for routine expenses.

At scale, that difference becomes enormous. 

• A 1,000-unit community handles 40 to 80 procurement transactions every month. 
• If each manual transaction consumes an average of four hours of combined time compared to a digital one, that is 160 to 320 hours of waste every single month. 
• That is the equivalent of two full-time employees spending their entire working hours managing the inefficiency of a broken process.

Embassy Group, which manages 36 properties on ADDA, documented a 50-minute reduction in documentation time per procurement transaction and a 60 percent drop in errors after implementing the advanced purchase workflow. The estimated savings from this one process came to 10 to 15 lakh rupees per community annually.

How Does ADDA Handle Large Communities and Developer Portfolios Differently?

This is where ADDA’s configuration depth becomes genuinely important, because a 200-unit self-managed RWA and multiple such communities being managed by a developer are not the same problem.

For large communities, or community portfolios, ADDA allows up to four levels of approval in both the PR and PO workflows, and these levels are configured based on the expense amount. 

A community can set it up so that:

• Any expense below 5,000 rupees is approved by the estate manager directly. 
• Between 5,000 and 25,000 needs the treasurer.
• Between 25,000 and one lakh needs the treasurer and secretary. 
• Above one lakh needs the full MC. The community defines these thresholds. The system enforces them automatically.

This matters because it respects everyone’s time while ensuring the right oversight for the right decisions. Committee members should not be pulled into approving a broken tap replacement. They absolutely should be in the loop when a 3 lakh generator repair is being sanctioned. The approval hierarchy does this automatically, without anyone having to decide on the fly who needs to be informed.

Approval Hierarchy Configuration: Configurable approval hierarchy — example setup for a large community 

For developers managing multiple properties, the workflows can be standardised across the entire portfolio. Every property follows the same process, the same approval thresholds, and the same documentation standards. A central operations team has visibility across all properties, seeing which transactions are pending, which are stuck, and which are complete. This is the difference between managing ten communities as ten separate chaos pockets and managing them as a structured portfolio with real governance.

So What Is the Actual Alternative to Legacy Tools Like Tally for Housing Societies?

The answer is a purpose-built community ERP where the P2P process, the accounting, and the financial visibility are all part of the same system, accessible to everyone with the appropriate role.

1. The estate manager raises the PR. 
2. The MC member approves it from her phone. 
3. The treasurer sees the budget impact in real time. 
4. The accountant posts the invoice and it is automatically linked to the approved PR. 
5. The auditor, when the time comes, logs in and pulls the complete expense trail in minutes. 

Nobody is waiting for a report. Nobody is dependent on whether the accountant is available that day. Nobody is managing community money through a desktop application that only one person in the entire society can actually operate.

In 2026, for a large community managing crores of rupees belonging to hundreds of families, that is the minimum standard of governance.

How Do You Get Started With a Proper Purchase Process for Your Society?

If your community is smaller, starting with just the PR and digital approval workflow is a meaningful step. Add budget visibility, then link invoices, then bring in GR/SR confirmation over time. You do not have to go from zero to full ERP overnight.

If you are a large community, a developer-managed township, or a company handling multiple sites, you need the full stack, configured properly from the start. The cost of not having it is not abstract. 

It shows up in wasted staff hours, audit complications, budget overruns that nobody caught in time, and sometimes in genuine financial irregularities that a proper system would have flagged before they became problems.

Because your residents deserve to know that the money they pay every month is being managed with the same transparency they expect from their bank, their mutual fund, and every other financial platform they use in their daily lives. Tally on the accountant’s desktop, in 2025, is simply not that.

ADDA Books is part of ADDA’s full-stack community management platform, used by over 25,000 residential communities across more than 10 countries, including large developer townships, PMC-managed properties, and self-managed RWAs.