Booking form to possession letter, in the order the sale goes.
Saudaflow files every paper against the booking it belongs to. Six documents down the legal chain, the loan and demand letters beside them, and the buyer’s KYC on its own track — each with a status somebody set, a desk that owes it, a version history nothing overwrites, and the registrar’s number on it the day you get one.
- Booking form → Possession letter
- Two forward-only status machines
- Every version kept, by database grant
- RERA Sec 13 advance gate
- Sales · Legal · Accounts · Post-sales
- Your buyer sees their own, and only theirs
The documents are created with the booking, not chased after it.
The moment a booking exists, Saudaflow writes one row per document from the checklist for that kind of sale — and the checklist is a setting, not our opinion. A loan-linked booking gets the tripartite agreement and the sanction letter. An NRI buyer gets passport and visa/OCI/PIO. A resale gets the prior ownership chain. A rental gets a rental agreement and three KYC items, and none of the rest.
-
01
Booking form
Sales
-
02
Allotment letter
Legal
-
03
Agreement for Sale
Legal · clears the RERA wall
-
04
Tripartite / NOC
Legal · loan cases
-
05
Sale deed
Legal
-
06
Possession letter
Post-sales
Beside the chain
Demand letters, the loan sanction letter and the loan file sit on the same wall with the same lifecycle — the accounts desk owns the sanction letter, and it is visible to the sales owner without an e-mail asking for it. Anything else your process needs is a custom row you add on the booking.
KYC on its own track
PAN, Aadhaar or an alternate ID, photograph, address proof, bank proof, specimen signature and the communication & data consent. Income proof appears when there is a loan; passport and visa / OCI / PIO when the buyer is an NRI. Identity has its own status machine because “verified” and “signed” are not the same word.
One row per document
A booking cannot hold two allotment letters. The database enforces one row per document key per booking, so “which one is the current one” is never a question — the current one is the latest version of the only row there is.
A status somebody set. Not a folder somebody sorted.
Both machines are forward-only. A document cannot jump from Pending to Signed because someone was in a hurry, and it cannot quietly walk backwards to hide a rejection. The server refuses the move and says why: a paperwork item cannot move from PENDING to SIGNED.
Paperwork
- Pending
- Drafted
- Under review
- Signed
- Registered
Sideways, and just as real: Returned for correction Rejected Archived. A rejection goes back to Drafted, never straight to Signed.
Registered needs the registrar’s number. Mark a document Registered without one and the server refuses the write: “the registrar’s registration number is required.” The number, the registration date and the registrar appointment are columns on the document, not a note somebody typed in a comment.
KYC
- Pending
- Collected
- Under review
- Verified
Sideways: Returned for correction Rejected Expired. An expired ID goes back to Collected — the buyer is not un-verified retroactively, the document is.
Verified stamps the reviewer. Who verified it and when are written on the row by the server, from the session doing the verifying. Nobody types their own name into that field.
Signing off is a separate permission
Moving a document to Signed or Registered needs the publish right on documents. Drafting it, sending it for review, returning it for correction and rejecting it need the edit right. The two are given to different seats on purpose — a coordinator who chases paperwork is not the person who declares it final.
Scope is checked before the machine runs
Having the permission is not enough. The server resolves the booking the document hangs off and checks it against the caller’s data scope — own, team, project, zone or org — before the status machine is even consulted, so the machine’s own error messages can never tell you about a booking you are not allowed to see.
Two people, one document
Status moves are written against the status they were validated against. If a colleague moved the same row while your dialog was open, your write does not silently win — it comes back as a conflict asking you to reload. On paperwork this matters more than it sounds.
Every document knows whose desk it is.
Each row carries the desk that owes it, and the booking screen groups the wall by desk rather than by date. “Legal has three, accounts has one, the customer has two” is a sentence your sales head can say in a review meeting without opening five folders.
Sales
The booking form, and any custom row your process puts on the sales desk.
Legal
Allotment letter, Agreement for Sale, tripartite / NOC, sale deed, and the prior ownership chain on a resale.
Accounts
Demand letters and the loan sanction letter.
Post-sales
The possession letter and what follows it.
The customer
Every KYC item. The wall says plainly when the ball is in the buyer’s court, so nobody chases the wrong person.
Desks are the shipped default and are editable per document. The org checklist decides who owes what on the way in.
The 10% wall, written on the line that crossed it.
Section 13 of the RERA Act says a promoter may not take more than 10% of the cost of the apartment as an advance before a registered Agreement for Sale. This is the one page on the site that gets to describe the rule properly, because documents are where the chain and the money ledger meet.
- Every receipt carries the check as it stood that day. Cumulative received, the cumulative percentage, the cap in force, whether the Agreement was registered, whether the line was flagged, and the message. Stored on the receipt row, permanently. Re-reading a booking two years later tells you what was true when the money came in, not what is true now.
- It flags. It does not block. Builders take money on terms they have already agreed; a CRM that refuses to record a receipt just moves the truth into a spreadsheet. So the booking is flagged, visibly, with the numbers on it, and the flag stays.
- It clears exactly one way. Mark the Agreement for Sale Registered, with the registrar’s number. That writes the agreement-registered fact on the booking, clears the flag, and records both an activity and an audit entry saying the flag was cleared by that registration. There is no “dismiss” button, and no way to clear it quietly.
- The cap is yours to set. 10% is the shipped default and the number in the Act. It is a column on the booking, so a project or a policy that needs a different figure uses a different figure — and each receipt records which cap it was judged against.
E-sign here is a workflow you drive. It is not an integration.
This page used to say Saudaflow sent documents for Aadhaar e-signature through eMudhra and NSDL. It does not, and it never did. What exists is the signing ceremony as a tracked, forward-only state on every document — which is genuinely useful, and is the thing worth describing.
- Not started
- Prepared
- Sent
- Partially signed
- Signed
- Declined
Each signer is recorded
Name, the moment they signed, and how. Two of three signatures in means Partially signed, and the wall shows who is still outstanding — which is the actual question your documentation desk is asked on the phone every afternoon.
Completion moves the paperwork
When the ceremony reaches Signed, the document’s own status walks with it — Drafted to Under review to Signed, one machine-checked hop at a time, each one logged. The signature is what advances the document; nobody has to remember to also flip the status.
No provider is connected
Not eMudhra, not NSDL, not Digio, not Leegality, not DocuSign, and no Aadhaar e-sign. The provider box on the panel is a label you type so the record says how a document was signed. Saudaflow tracks the signing you already do, wherever you do it, and moves the chain on when it completes.
Nothing is overwritten. That is a database grant, not a promise.
Every upload against a document becomes the next numbered version, carrying the file, who uploaded it, their note, and the status the document was in at that moment. The fourth draft of an agreement does not replace the third; it follows it.
The application cannot rewrite history
The version table and the file table are granted select and insert only to the role the API runs as. Not “we do not update them” — the database will not let the application update or delete them at all. The same posture covers the audit log, where update and delete are revoked from both runtime roles.
An uploaded filename never becomes a path
The name your colleague’s laptop gave the file survives only as a display label. On disk the file is a server-generated identifier inside that organisation’s own directory, with an extension taken from the allowed type list, and every read re-checks that the path it resolved is still inside that directory.
Four things are audited on every document
Created, updated, status changed, version uploaded — each with the actor, the values before, the values after and the time. The booking’s own activity feed carries the same events in plain language, so the trail is readable by the person who needs it and not only by an engineer.
Legal remarks can be hidden from seats that should not read them
The compliance remark on a document is a maskable field: a seat whose role does not carry legal-remark visibility does not get it in the response at all. Field-level masking happens on the server, so it is not a matter of the screen politely not rendering it.
Your buyer can see their own paperwork without anyone e-mailing a zip.
If you switch on Buyer Connect, a buyer with a booking signs in and sees their documents: the title, the status your team set, and a download button only where a real file exists behind it. “Has my agreement been registered yet?” stops being a phone call to your documentation desk.
What is withheld, and why it matters
Internal notes, the compliance remark and the e-sign metadata are never selected by the query that serves the buyer. They are not hidden by the front end — they do not leave the server. Those are your team’s working record about a buyer, not a document for them.
The id in the URL is proved, not trusted
A document is fetched by a query whose conditions already contain that session’s organisation and that session’s contact, joined through the booking. Another buyer’s document, another builder’s document and an id that never existed all produce the same 404. Downloads are marked private and no-store — never a shared cache, never a CDN edge.
One thing to know first
The sign-in code that Buyer Connect sends by SMS is not live yet. Codes are generated and rate-limited and every screen behind them works, but sending a transactional SMS in India needs a DLT-registered sender and template with TRAI, and that registration is still in progress. Rehearse with it; don’t print the link on a possession letter yet.
Give a document a due date, and the person who owns the booking hears about it.
The reminder, described exactly
A required document past its due date raises one notification to the booking’s owner, once in any 24 hours, naming the oldest overdue item and how many there are. It fires the day the date passes — not before it — and it stops when the document is signed, registered, verified or archived. It arrives in the app; switch the e-mail channel on for it and the same notification is e-mailed too — e-mail is the one external channel that is live today. There is no Slack hook, and WhatsApp is waiting on its own credentials.
Channels are set per event, per role and per person, so this is a switch you own rather than a default we chose for you.
KYC & document readiness
A shipped report: required against verified against rejected, across bookings and channel partners, with the blocking items named rather than a percentage on its own. Every row drills into the booking behind it, and the whole thing exports to CSV, Excel or PDF. A row with nothing required reads 100%, because inventing a penalty would be a lie.
Both the wall summary and the report count “done” the same way — paperwork is done at Signed or Registered, KYC at Verified — so the number on the booking and the number in the report never disagree.
The short list of things this page used to claim, and does not have.
This page was rewritten in September 2026 because the version before it described a security architecture belonging to a different module and two e-signature vendors that were never connected. Everything above is in the product today. Here is what is not, in the same place, in the same type size.
-
No e-signature provider
You cannot send a document for signature from Saudaflow. The six-state workflow above is real and useful; the integration behind it is not built.
-
No share links
There is no expiring link, no read-once mode, no OTP-gated link and no watermark — there is no document sharing route at all. Buyer Connect, where a buyer signs in and sees only their own booking, is the sharing mechanism.
-
Documents are not encrypted file by file
They are stored on the server’s own disk, not encrypted per file with their own key. What protects them is access control the database enforces — row-level tenant isolation that denies by default, permissions with a data scope, files written under the organisation’s own directory, insert-only grants, and staff access recorded in a log the customer can read and nobody at Saudaflow can edit. We would rather write that sentence than the one that was here before.
-
No document classifier
Nothing guesses what an uploaded file is. It does not need to: the slot was created from the checklist when the booking was made, so a file is uploaded into a document rather than sorted after the fact.
-
No stamp-duty calculator
Stamp duty, registration charges and GST appear on the cost sheet as statutory charges, kept separate from the builder’s own line items. There is no per-state duty engine.
-
The document wall is a web screen
The Android field app does calls, visits, inventory and approvals. It does not carry the document wall yet, and there is no iPhone build at all. Documentation is desk work, and that is where it lives today.
Asked on every documentation call.
If yours is not here, ask it on the demo — or write to support@saudaflow.in. Support is open 09:30–19:00 IST, every day.
Can I send a document for e-signature from Saudaflow?
No. No e-signature provider is connected — not eMudhra, not NSDL, not Digio, not Leegality, and no Aadhaar e-sign. Any page that told you otherwise was wrong and has been rewritten.
What you can do is track the ceremony you already run: mark the document Prepared, then Sent, then Partially signed as signatures come in, then Signed or Declined. Each signer is recorded with the time and the method, and when it completes the document’s own status walks forward with it. The provider box is a label you type, so a year later the record still says how that agreement was signed.
Can I share a document with a buyer by link?
Not by link. There is no share route in the product — no expiring URL, no read-once, no OTP gate on a link, no watermark. Those were claims on the old page and none of them had code behind them.
The buyer sees their paperwork by signing in to Buyer Connect, where the query that fetches a document already contains their own contact and their own booking. That is a stronger guarantee than a link with a short expiry, because a link that leaks is still a link that works.
What happens if we collect more than 10% before the agreement is registered?
The receipt is recorded — refusing to record money a builder has actually taken only moves the truth into a spreadsheet — and the booking is flagged, with the numbers stored on the line that crossed the cap: how much had been received, what percentage of the unit value that was, the cap in force, and whether the Agreement was registered at that moment.
The flag clears when the Agreement for Sale is marked Registered with the registrar’s number, and that clearing writes its own audit entry. The cap defaults to 10% and is a setting; each receipt records which cap it was judged against, so changing it later never rewrites the past.
Can we change the document checklist?
Yes. The shipped list is a default, not a cage: your organisation’s own checklist replaces it, and after that every new booking is created from your list, with your titles, your desks, your ordering and your view of what is required.
The default already varies by case — loan-linked bookings get the tripartite agreement, the sanction letter and income proof; NRI buyers get passport and visa / OCI / PIO; a resale adds the prior ownership chain; a rental gets a rental agreement and three KYC items instead of the whole sale chain. You can also add a one-off custom document to a single booking without touching the template.
Who can mark a document Signed or Registered?
Only a seat with the publish right on documents. Drafting, sending for review, returning for correction and rejecting all need the edit right instead — a deliberate split, so the coordinator who chases paperwork is not the person who declares it final.
On top of that, the booking itself has to be inside the caller’s data scope. The scope check runs before the status machine, so someone outside it gets the same answer for a document that exists as for one that does not.
Are documents encrypted?
Not file by file, and we are not going to say otherwise. Uploaded files live on the server’s disk, under the organisation’s own directory, with server-generated names. Call recordings are the part of Saudaflow that carries per-file encryption; documents do not, and the old version of this page described the recordings design as though it covered them.
What is true: tenant isolation is enforced by the database and denies by default, every read is checked against the caller’s permission and data scope, the file and version tables are insert-only for the application, the audit log cannot be updated or deleted by the running system, and Saudaflow staff access to your workspace for support or compliance is written into a log you can read and we cannot edit.
Will it chase people for us?
Within limits worth stating plainly. Give a required document a due date and, on the day it goes past that date, the booking’s owner gets one notification naming the oldest overdue item and the count. It repeats at most once a day and stops when the document is signed, registered, verified or archived.
It arrives in the app by default. Turn the e-mail channel on for that event and it is e-mailed as well — e-mail is the one external channel live today. Push is built and waiting on credentials; WhatsApp is waiting on its own.
It does not warn you in advance, it does not watch expiry dates, and it does not message the customer directly. If that is what you need, say so on the call — it is a small change and we would rather build it than describe it as though it were already there.
Bring one live booking to the call.
Thirty minutes. We set up your workspace, put one of your real projects and one real booking into it, and walk the document chain end to end — including the RERA advance flag, on your own numbers.
Documents are part of every plan. No card, no self-serve signup, and the prices are on the pricing page rather than behind the call.