IPOxCardsHow to track IPO applications across multiple demat accounts
A practical account-level system for managing many demat accounts under one user, preventing duplicate records and keeping allotment, funding and profit data aligned.
The hardest part of a multi-demat IPO operation is not counting applications. It is preserving the identity of the exact account that applied, the bank that funded it and the person who receives the result.
One private admin boundary
One person profile
Every account labelled
Issue and schedule
Lots + bank + state
Allotted + result
Each step should have one clear owner, one source record and one review point.
Why a flat spreadsheet becomes unreliable
A flat sheet often starts with a person’s name and a few checkboxes. As more accounts are added, names are shortened, broker labels are reused and results are entered against the wrong row. A total can still look plausible even when the underlying mapping is wrong.
The fix is not more colours. It is a relationship model where each record has a stable owner:
Step 1: create one profile per person
Use a single profile for the person who has provided one or more accounts. Store the person’s permitted contact and onboarding information once. Do not create a new “user” every time that person adds another demat account.
Step 2: add each demat as a separate record
Each account should have its own holder name, PAN, DP ID or account identifier, broker or DP label, status and profit-share rule. This makes it possible to answer simple operational questions: Which accounts were applied? Which bank was used? Which account was allotted? Which account has a pending result?
- One account record per real demat account.
- A unique DP or account identifier inside the workspace.
- A readable label that appears in lists and reports.
- A clear owner profile.
- A review or approval step for additions and removals.
Step 3: make the IPO application account-specific
When an IPO is selected, mark the exact demat accounts used. Record lots, planned amount, application status and—when your process needs it—the funding bank. The same user can have one account applied and another account not applied, so a user-level checkbox alone is not enough.
| Record | What it answers | Should change later? |
|---|---|---|
| Demat account | Whose account is this? | Only through controlled edit |
| IPO application | Did this account apply? | Yes, with an audit trail |
| Allotment outcome | Was it allotted? | Yes, reversible before close |
| Result entry | What happened after sale? | Yes, with an explicit correction |
Step 4: keep status transitions visible
Use separate states for applied, allotted, not allotted, sold and settled. Allotted and not allotted should be mutually exclusive. A correction should undo the mistaken state instead of silently changing historical data.
Step 5: reconcile the user view with the admin view
Every source record should have a single calculation. Admin dashboards can aggregate the workspace, while the user view filters to the user’s own records. If the total profit changes in admin, the user’s account-level history should update from that same source rather than from a second manually maintained total.
- The user sees only linked demat accounts.
- The admin sees the exact account label in every result.
- Gross result and charges are stored once.
- The configured share is visible and explainable.
- Past IPO history is retained after the workflow closes.
Common failure modes
- Duplicate profiles created for the same person.
- Two account records share the same identifier.
- A result is entered against a user but not an account.
- “Applied” is inferred from a planned funding amount.
- A private PAN or bank detail is displayed in a public page or export.
Quick answers
Should I create one row per person or per demat account?+
Use one user profile for the person and one separate demat record for every account. Applications should always point to the exact demat record.
What should a demat label contain?+
Use a short human label that distinguishes the account, such as the holder name plus broker or DP suffix. Keep the complete PAN and DP data protected behind authentication.
How do I prevent an account being counted twice?+
Use a unique DP or account identifier within the workspace, validate it during onboarding and show the label in every application, funding and result view.