The hardest part of a wedding budget is not the numbers. It is the politics. Two extended families, three or four decision-makers, an unclear contribution split, and a calendar of cash advances paid by different hands to different vendors — and at the end of it, somebody has to reconcile who owes whom. We have watched families go from warm to cold in the final week of a wedding over a misplaced ₹40,000 advance. The math was correct. The trust had failed.

A wedding budget that survives the in-laws is not a more detailed spreadsheet. It is a different way of organising the information so that every contributor can see, at any moment, what is owed and what is paid.

The two-ledger model

The version that works is structurally simple. You keep two ledgers.

The first is the commitment ledger — a list of every line item somebody has agreed to, with the vendor, the amount, the payment schedule (if any), and the responsible party. Caterer: ₹6,80,000, paid by the groom's side, in three instalments. Decorator: ₹2,40,000, paid by the bride's side, lump sum on delivery. Photographer: ₹95,000, split equally, 50 percent advance, 50 percent on delivery. Every commitment is one row.

The second is the payments ledger — a list of every actual cash or bank transfer made, with the date, the amount, the payer, the payee, and a reference to which commitment it pays toward. This is the source of truth for what has actually happened. It looks more like a bank statement than a plan.

The dashboard is a derived view. Sum the commitments by category and by contributor. Sum the payments by commitment. Subtract. Show three numbers for every line: committed, paid, outstanding. Show four numbers for every contributor: total committed, total paid, balance owed to other party, balance owed by other party.

The whole model fits on one screen. The reason it works is that there is exactly one place to update each kind of fact: when a commitment is made, it goes on the commitment ledger; when a payment happens, it goes on the payments ledger. Nobody has to remember to update the dashboard. The dashboard is the calculation, not the source.

Why this beats the spreadsheet

A typical wedding spreadsheet conflates the two ledgers. The same row holds both "we plan to pay ₹6.8L to the caterer" and "we paid ₹2L on the third of March." When a third party — say the bride's father — sees a row that says "caterer ₹6.8L, paid ₹2L," they cannot tell who paid the ₹2L. They cannot tell whether the ₹4.8L outstanding is owed by their side or the other side. They cannot tell whether the next instalment was meant to be paid by them or not.

Splitting the ledgers fixes this. Every commitment row says explicitly: this amount is owed by X. Every payment row says explicitly: this amount was paid by Y. The math then trivially reconciles "who has paid more than their fair share" without anyone having to ask.

Categories matter less than you think

Most wedding budget tools spend a lot of design effort on category lists — venue, catering, decor, photography, attire, jewellery, transport, hospitality, miscellaneous. Categories are useful but they are not the governance mechanism. We have seen perfectly tagged budgets fall apart and completely untagged budgets work fine, depending on whether the two-ledger discipline was followed.

A reasonable rule of thumb: pick at most 8 categories, and use them only for reporting (where is the money going?), not for governance (who owes what?). Governance is by contributor and by commitment. Reporting is by category. Conflating the two is the fastest way to a budget meeting at 11pm the night before the haldi.

Cash payments are real and must be tracked

A great deal of wedding spending in India happens in cash — to the priest, to the band, to incidental vendors. The temptation is to keep cash payments out of the budget tool ("we will add them later"). The temptation is wrong. Every uncategorised cash payment is a future argument.

The pattern we recommend: a "cash float" entry in the payments ledger, re-balanced weekly. ₹50,000 withdrawn from the joint account becomes one payment ledger entry. Each cash disbursement out of the float is a child entry against the same float. When the float runs low it is topped up with another ledger entry. The float runs to zero by the end of the wedding, and every rupee is accounted for.

This is the only part of the model that takes real discipline. It is also the part that, when done well, ends the post-wedding "where did all the cash go?" conversation in one minute instead of three weeks.

Reconciliation is a feature, not an audit

The final reconciliation — who owes whom how much at the end — is the moment the system either pays off or fails. A good budget tool produces, at any moment, a one-line reconciliation: the groom's side has paid ₹X more than their committed share; the bride's side owes ₹Y on outstanding commitments; the net settlement is ₹Z from one party to the other.

This is a calculation, not a debate. If the commitment ledger is honest and the payments ledger is current, the reconciliation is correct. Families arrive at the post-wedding settlement meeting with a number, agree on it in under five minutes, and go back to being family. Families that did not run this discipline arrive at the meeting with two opposing spreadsheets, an hour of explanation, and a residue of mistrust that lingers past the honeymoon.

What we are not solving

Two things this model does not address. First, the question of who should pay for what — that is a family conversation, not a software conversation, and we have no view on it. Second, hidden personal generosity — the grandparent who quietly slipped the bride ₹2L without telling either side. Those gifts are not commitments and we do not track them.

If your wedding budget is the source of tension in your house this month, the fix is almost certainly not a better spreadsheet. It is a clear separation between what has been promised and what has actually been paid, visible to everyone with skin in the game. The math will take care of itself.