Summary: This is a general news/document presenting a booklet that explains when organisations should continue using spreadsheets, better utilise an existing database, or build a new one. Using fictional examples of a tea stall, a manufacturing company and a chartered accountancy firm, it contrasts Excel with databases, emphasising that databases provide a shared, current record while spreadsheets create separate working copies. The booklet discusses themes including deciding what information should be recorded, recognising the limits of individual memory, achieving a common understanding of data, reducing delays caused by information flow, and avoiding multiple versions of the same record. It explains that some organisations already possess suitable databases but need better reporting, while others may require a new database-based system. Appendices describe database concepts such as tables, keys, constraints, transactions, permissions, backups and indexes in non-technical language, outline approaches for implementing a database either internally or with external assistance, and provide illustrative workflows showing how database-based processes can replace Excel-based workflows for manufacturing and audit activities.
Preface
Why this booklet:
a) Why does your office need a database in addition to various spreadsheets (Excel). If you are convinced that your office needs a database, there are two possibilities. In either case, jump to last chapter:
1) In case you are having a database, you might find that you are not making appropriate use thereof.
2) You do not have a database; you will get to know what to do to have one which is relevant considering the nature of activities and size of business.
When to stop reading:
b) When you will get convinced that in your office, in addition to excel files, you need a database. Refer to Appendix 3.
c) Sooner you stop reading, higher will be success of this booklet.
Why it is getting dragged:
d) This booklet is meant even for an undergraduate student who has used excel but does not have any working experience.
| Particulars | Page No | Particulars | Page No | ||
| From | To | From | To | ||
| Entering the Subject | 02 | 02 | Episode -4 -: Identifying limitations of a person | 07 | 07 |
| Story Telling | 03 | 03 | Episode -5 -: Consensus ad Idem | 08 | 08 |
| Episode -1 -: Meet the cast | 04 | 04 | Episode -6 -: Identifying Organization’s Needs | 09 | 09 |
| Episode -2 -: Deciding what is worth recording… | 05 | 05 | Episode -7 -: Mere sharing is not sufficient | 10 | 10 |
| Episode -3 -: Multiple versions of truth | 06 | 06 | Episode -8 -: Asking questions… | 11 | 12 |
–
| Particulars | Page No | |
| From | To | |
| Appendix – 1 – What database Actually Is | 13 | 16 |
| Appendix-2: Codifying requirements in the context of a database | 17 | 21 |
| Appendix-3: Translating the Stories into real life | 22 | 26 |
Entering the Subject
What is a Database
a) An understanding in the context of Excel.
1) An Excel file is one workbook, with sheets, that lives on one person’s laptop (or a shared drive) at a time. When you open it, you get a copy of the data. If two people open the same file, one of them is looking at a stale copy the moment the other saves a change.
2) A database is the same basic idea — rows and columns holding information — but built to be looked at, and changed, by many people at the same time, with the system itself making sure everyone always sees the current, correct version. That’s the single biggest difference: Excel is a document. A database is a service.
1) In brief, you can summarise as follows:
1) A brief Excel is a very good notebook.
2) A database is a very good clerk — one who never gets tired, never mixes up two people’s edits, remembers who wrote what and when, and always gives everyone in the building the same answer to the same question at the same moment.
For People with less patience (Gen Z)
c) This book does not talk about any database in particular. A writeup has been appended at the end that explains the characteristics of a database in non-technical terms.
d) This book was not written because organizations need more software but because organizations with good software still struggle to build one shared understanding.
e) Summary of themes discussed.
1) Reality happens before it is recorded.
2) Discipline begins not by recording more information, but by deciding what is worth carrying into tomorrow.
3) Different reports are not evidence of failure. They are evidence that different people are answering different questions.
4) Growth quietly reaches a point where one person’s memory is no longer sufficient for the organization.
5) Growth does not weaken memory. It exposes its limits.
6) People can work together only when they mean the same thing by the same words.
7) A record is only as good as the reality it was taken from. Writing faster is not the same as writing better..!!
Story-telling
Three stories —
f) Three stories guide the journey:
a. Anna’s Tea Stall,
b. Shakti Precision, and
c. K&D Associates, Chartered Accountants.
g) They are separated by size and by purpose, not by principle.
d. Anna serves tea.
e. Shakti manufactures precision parts.
f. K&D audits both kinds of businesses as mentioned above, and hundreds like them.
h) Brief about above.
g. ‘Anna’ will end this book still holding only a notebook.
h. Shakti will discover it already owns a database and has simply never asked it the right question.
i. K&D will build a database for the first time, because for what it does, nothing less will do.
i) Each episode below walks through all three, one at a time, before pulling the thread that connects them. The scale is never the same. The lesson always is.
Episode -1 -: Meet the cast
Anna’s Tea Stall
a) Anna, a tea stall owner
For twenty years, he has served tea to everyone—from newspaper vendors to bank managers.
He remembers most customers by face, many by name, and a surprising number by what they usually drink.
He never studied management.
Yet every morning he manages suppliers, customers, credit, cash, helpers and inventory without calling any of it “management.”
Shakti Precision
b) The company is into manufacturing precision tools.
Every morning at 8:45, Rajesh, Plant head, enters the factory fifteen minutes before everyone expects him.
Ravi, a store manager can identify most raw materials from a few metres away.
Meena, know for asking right questions, is a project in-charge.
Iqbal, IT Manager known to have confidence in his system as deep as law of gravitational force.
K&D Associates
c) A CA firm conducting audits of various entities of all types.
CA Kapoor, a Partner, with 30 years of experience firmly believes that most mistakes begin with assumptions, not calculations.
CA Deshmukh, a younger partner, constantly looks for better ways of working so that the firm can grow without becoming chaotic.
Manish, an Audit Manager firmly believes that work not documented is work not done.
Farah Another Audit Manager, has imbibed the philosophy to go by evidence from CA Kapoor
The Articled Assistants
Every year, a new batch of articled assistants joins K&D. In this book, you will meet Priya, Rohan, Kunal, Neha, Varun and Aditi. As they learn, you will learn with them.
The common thread:
d) A record is only as good as the reality it was taken from. Writing faster is not the same as writing better..!!
Episode -2 -: Deciding what is worth recording…
Discipline begins not by recording more information, but by deciding what is worth carrying into tomorrow.
a) A busy day leaves behind thousands of moments. Only a few deserve to become business memory.
Anna’s Tea Stall
b) Anna notices his helper writing everything. He gently tears out one page and says, “A notebook should help tomorrow, not preserve yesterday.” Together they re-design the notebook so that every line has a purpose.
Shakti Precision
c) Meena projects an Excel dump containing dozens of columns. She asks the room to imagine tomorrow’s production meeting if every column disappeared except five. Which five would everyone fight to keep? The discussion suddenly becomes energetic.
K&D Associates
d) Kunal has exported the entire Tally Day Book for a client — eleven thousand entries, forty-two columns, most of them blank. CA Kapoor scrolls through it once and asks the room, “For confirming this year’s receivable balance, how many of these columns will actually go into the audit file?” Nobody has counted before. The answer, once they count, is four. The remaining thirty-eight are not audit evidence. They are simply extra weight the export brought along.
The common thread:
e) Nobody in any of the three rooms asks for another report. Everyone begins defending the information they truly need.
Episode -3 -: Multiple versions of truth
Different reports are not evidence of failure. They are evidence that different people are answering different questions.
Anna’s Tea Stall
a) Anna finds that his notebook and a customer’s UPI receipt tell different stories. Within minutes he discovers that yesterday’s payment was never entered. Nobody loses trust because everyone searches for the event instead of blaming the person.
Shakti Precision
b) Monday’s review begins with four Excel extracts from SAP. Sales, Production, Finance and Stores all trust their reports because each report was built for a legitimate purpose. Rajesh walks to the whiteboard instead of looking at the numbers. He writes four questions — “What was sold?”, “What was produced?”, “What was invoiced?”, “What was received?”
c) Then he points to the reports. “Perhaps these reports are not disagreeing. Perhaps we are asking them to answer the wrong question.” The atmosphere changes. The meeting stops defending numbers and starts understanding context.
K&D Associates
d) Four students are auditing the same client from four different Tally exports — the Trial Balance, the Ledger, the Day Book and the Bank Reconciliation statement. Rohan is convinced two of the reports are wrong because the closing balances don’t tally. Farah, the manager, walks him through each export’s filter settings — one was run as on 31st March, another as on the date of extraction, two weeks later. “They were never disagreeing,” she says. “They were answering questions from two different dates.”
e) That evening the point goes into the audit programme: before comparing two Tally exports, confirm they were pulled with the same filters, on the same date.
The common thread:
f) Before comparing answers, make sure everyone is answering the same question.
Episode -4 -: Identifying limitations of a person
Growth quietly reaches a point where one person’s memory is no longer sufficient for the organization.
Anna’s Tea Stall
a) Business has grown. Two helpers now work alongside Anna. Regular customers, monthly credit accounts, milk deliveries and digital payments all flow through the day. One evening a customer smiles and says, “Anna, I paid last week.” Anna pauses. He genuinely cannot remember. He opens the notebook instead. They both smile when the entry is found. Nobody feels offended. The notebook has protected both memory and trust. Anna returns home thinking about something unusual — his memory has not become weaker. His business has become larger.
Shakti Precision
b) Rajesh chairs the weekly review. SAP contains every transaction. Yet before the meeting begins, each department has already downloaded fresh Excel extracts for analysis. During the discussion, Ravi says, “Last week’s rejection trend looks familiar.” Meena replies, “Let’s verify it instead of relying on memory.” Within minutes the SAP history confirms the observation. The discussion ends without debate.
K&D Associates
c) The firm has grown from twelve audit clients to sixty in four years. CA Deshmukh once knew, without checking, which student was posted where, and which client had a calendar-year-end instead of March. She notices, one Monday, that she can no longer answer either question from memory. She asks Suresh, the newest manager, to check. He finds there is no single place to check — the information lives across six students’ inboxes and three managers’ notebooks. That evening the firm starts a shared engagement tracker: nothing fancy, just a spreadsheet everyone is asked to update. It is not a database. It is, for now, enough.
The common thread:
d) Nobody has replaced SAP. Nobody has abandoned Excel or Tally. But in all three places, memory has quietly stopped being the final authority. That evening Anna buys a better notebook with indexed pages. Meena creates a shared folder for the meeting extracts. Neither change is dramatic — both reduce dependence on individual memory and increase dependence on shared organisational memory. At K&D, the new tracker will not survive the year unchanged. Nobody knows that yet.
Episode -5 -: Consensus ad Idem
People can work together only when they all understand the same thing in the same manner at the same time
Anna’s Tea Stall
a) Anna has hired another helper. During the morning rush one helper asks for the “strong tea mix”. Another asks for the “special tea powder”. Anna smiles — both are pointing to the same container. That evening he labels every container. Tea Leaves. Sugar. Cardamom. Ginger. Nobody requested labels. Anna simply knows that tomorrow’s helper should not have to guess.
Shakti Precision
b) Ravi is inducting a graduate trainee in the stores. The trainee points to a stack of steel and says, “Where should I keep this raw material?” Ravi replies gently, “Before deciding where to keep it, let’s decide what to call it. Production calls it Body Panel Sheet. Purchase calls it CRCA Coil. The supplier invoice calls it Item 410. SAP knows it by a material code. If each of us uses a different name, we’ll spend more time translating than working.” Later that day, Sales refers to a customer as “ABC”. Finance calls the same company “ABC Industries Private Limited”. Dispatch knows it only by a customer code. Meena pauses the discussion: “Before comparing numbers, can we first agree that we are talking about the same customer and the same material?” Five minutes are spent agreeing on names. The next forty-five minutes become surprisingly smooth.
K&D Associates
c) Varun searches the engagement tracker for “ABC” and finds three rows — one client, three different spellings, entered by three different students on three different days. CA Kapoor asks the firm to agree on one rule: every client is referred to, in every file and every email, by its firm-issued client code first, and its trade name second. It takes an afternoon to rename everything. It saves, over the coming months, a great deal of searching.
The common thread:
d) “Perhaps organisations don’t become efficient by speaking more,” Rajesh remarks. “They become efficient by meaning the same thing.” Anna’s labels remain unnoticed by customers. Ravi’s explanation is forgotten by the trainee within a few weeks. Yet all three organisations have quietly reduced future confusion.
Episode -6 -: Identifying Organization’s Needs
Organizations rarely stop because people are unwilling to work. They stop because work waits for information.
Anna’s Tea Stall
a) Nobody is idle during the morning rush, yet tea is not reaching customers as quickly as before. One helper keeps asking, “Is this customer on monthly credit?” Another asks, “Extra sugar or regular?” Every answer comes from Anna. The work is waiting for information. That evening Anna prepares a small laminated reference card showing regular credit customers and common tea variations. The next morning the same team serves more customers without working any harder. They simply wait less.
Shakti Precision
b) The weekly dispatch meeting begins. SAP contains the latest transactions, but before dispatch can proceed, each department waits for someone else’s Excel extract to arrive by email. Production waits for Quality’s workbook. Quality waits for Dispatch’s reconciliation. Finance waits for Production’s final quantity. Every team is busy. The organisation is waiting. Rajesh quietly asks, “If SAP already knows these transactions, why are we waiting for four emails before making one decision?” Meena sketches the information flow on a whiteboard. The delay is not caused by approval — it is caused by every department creating its own intermediate Excel file before sharing information.
K&D Associates
c) Fieldwork finishes on time most weeks. Sign-off does not. Neha’s workpaper sits in Manish’s inbox for two days before he reviews it. His consolidated file sits in CA Kapoor’s inbox for two more before the partner opens it. Nobody is idle — everyone is working on something else while they wait. CA Kapoor totals it up one evening: across the firm’s sixty clients, review is waiting an average of four days per file, not because anyone is slow, but because every handoff happens by email, one attachment at a time. “We are not short of hours,” he tells the managers. “We are short of a place where the file is simply already there, waiting for the next person, instead of waiting for the next email.”
The common thread:
d) Anna reduces waiting with a reference card. Shakti reduces waiting by agreeing on a common starting point. K&D has, for the first time, named its waiting — but has not yet fixed it. Neither Anna nor Shakti has changed technology. Both have improved the flow of work.
Episode -7 -: Mere sharing is not sufficient
A shared system of records does not automatically create a shared understanding. The gap often appears after data is exported.
Anna’s Tea Stall
a) Anna’s tea stall has grown further. His nephew maintains the credit notebook. Another helper maintains the milk purchases. At closing time Anna spends a few minutes bringing both notebooks together before counting the day’s cash. “If we leave them separate,” he says, “tomorrow we will begin with different stories.”
Shakti Precision
b) The monthly review meeting begins exactly at 9:00 a.m. Every participant opens a laptop. SAP has already captured the business transactions. Yet no one begins by looking at SAP. Sales opens Sales_Review.xlsx. Production opens Production_Daily.xlsx. Finance opens Dispatch_Recon_Final.xlsx. Purchase opens Vendor_Status_v4.xlsx. Every workbook has been exported from SAP; every workbook now carries its own calculations, hidden columns, colour codes and personal notes.
c) Rajesh asks the room, “How many versions of today’s business are present in this room?” Nobody answers. Meena walks to the whiteboard and draws three boxes — Business, SAP, Excel — then five arrows leaving the Excel box, one towards each department. “The business happened once. SAP recorded it once. We created five different working copies.” Ravi adds, “None of us realised we were slowly creating five organisational memories.”
K&D Associates
d) CA Kapoor asks a similar question at the year-end review of one client: “How many copies of this Trial Balance exist right now, across this team?” Aditi checks. There are six — one exported by each articled student, at six different times from Tally, each with their own tick marks, their own rounding, their own added columns. Tally recorded the client’s trial balance once. The team created six separate memories of it. “None of you did anything wrong,” CA Kapoor says. “Each of you built exactly what you needed for your own section. But the firm now has six answers to one question, and I have to decide, tonight, which one to sign.” He picks one by hand and asks the other five to be archived.
The common thread:
e) No software changes that day, anywhere. Yet all three — a tea stall, a factory, and an audit firm — arrive, from three different directions and three different scales, at the edge of the same realisation.
Episode -8 -: Asking questions…
A database is not always something you need to buy. Sometimes it is something you may already own and have simply never asked to speak. And sometimes there is genuinely nothing there yet, and something must be built.
Anna’s Tea Stall
a) Anna needed neither. His ledger of transactions never grew past what one indexed notebook, reconciled each evening, can hold. Nobody sits him down to explain databases, and nobody should — the correct answer, for Anna, remains a notebook, and knowing that is as important as knowing the opposite for the other two.
Shakti Precision
b) A few weeks after the six-workbook meeting, Rajesh calls Meena and Ravi into his office with a whiteboard marker and no laptop. “We have spent a year fixing how we behave around Excel,” he says. “Agreeing on names, agreeing on dates, agreeing on who waits for whom. What if the actual problem was never that we lacked a database?”
c) Meena says what has been obvious the whole time, and unnoticed for exactly that reason. “SAP is a database. It has been one since the day we installed it. Every transaction Shakti has made for years already lives inside it, correctly, in one place, connected, available the instant it happens. We were never short of a database.”
d) Ravi asks the question that follows naturally. “Then why does everyone still export to Excel first, every single time?”
e) “Because nobody ever asked IT to build the report we actually wanted,” Meena says. “We solved a data problem with willpower, when it was a request we had simply never made.”
f) The following week Rajesh sits down with Iqbal, the plant’s IT manager — not to discuss new software, but to describe three decisions the departments make every day, and the exact question each one needs answered. Quality wants the day’s rejection trend by shift, visible the moment it happens. Finance wants overdue receivables by GSTIN, refreshed automatically every night.
g) Production and Dispatch want their quantities reconciled on one screen, not two workbooks compared by hand. Iqbal writes down three queries against the database that has been sitting there, fully capable, the entire time. Within a fortnight, all three reports exist inside SAP itself. Nobody has to remember to export anything, because there is nothing left to export.
h) “We didn’t need a new system,” Rajesh tells the next review meeting. “We needed to ask the one we already had to speak in the language we actually work in.”
K&D Associates
i) The six-Trial-Balance evening does not fade quietly. Two months later, a junior partner nearly signs off a client using a workpaper built on the wrong one of the six copies — caught only because Aditi happens to notice her tick marks are missing from it. Nobody is blamed. But CA Kapoor and CA Deshmukh sit down that weekend with a question Shakti never had to ask: unlike SAP, Tally was never built to hold six students’ work on one client at once, with review trails, sign-offs and version history. There is no database sitting quietly underneath, waiting to be asked the right question. For what the firm needs — one client, one set of workpapers, six people, three levels of review, one final sign-off, and a record of who touched what and when — there is, at K&D Associates, genuinely nothing there yet.
j) So they build it. Over the following two months, the firm moves to an audit management system with a proper database at its core. Tally data is imported once, into one place, for each client. Every student’s workpaper links back to those same underlying figures — not a copy of them. A manager’s review and a partner’s sign-off are recorded against the file itself, with a timestamp, not scattered across email threads. When Priya, Rohan, Kunal, Neha, Varun and Aditi open a client file now, all six of them are looking at the same Trial Balance, because there is, for the first time, only one.
k) “Shakti already had a database and didn’t know it,” CA Kapoor tells the managers, once the new system is running. “We didn’t have one at all. That’s the whole difference between the two of us — one of us needed a conversation with IT. The other needed to build something new.”
The common thread:
l) Three organisations, three different answers, one shared discipline underneath all of them: know what question you are actually trying to answer, know where the true record of it already lives, and only then decide whether you need to ask better questions of what you have — or build, for the first time, a place where the answer can finally live in one copy, not six.
Appendix-1: Understanding database in some more depth
A promise was made early in this booklet: that the stories would carry the argument, and that anyone still curious about the machinery underneath could find it here, at the end, not mixed into Anna’s notebook or Shakti’s whiteboard. This is that write-up.
Nothing here names a particular product. That choice comes later, once the need itself is settled. What follows are the handful of technical ideas that every real database shares, whichever one an office eventually picks.
Rows, Columns, and Why a Table Is Not a Sheet
A table looks like a sheet.
a) It has rows and columns, and for a moment that resemblance is comforting. Underneath, it is not one. A sheet is drawn freehand — a person decides, cell by cell, what goes where, and nothing stops a date from landing in a column meant for amounts.
b) A table is declared in advance. Before a single row is entered, someone states:
i. this column holds a date,
ii. this one holds a whole number,
iii. this one holds text of at most forty characters.
c) The table then enforces its own shape, every time, without being reminded.
A row is one fact, complete.
e) One customer. One invoice. One day’s stock count. The column names do not travel with the row — they are fixed once, above every row, the same for all of them. This is the opposite of an Excel habit where a stray note in row 4004 quietly breaks the column meant only for numbers in the other 4,003 rows.
f) This is why Meena’s five columns and Kunal’s four columns, from earlier episodes, are not a coincidence. A table asks, once and for everyone, exactly which columns exist. Nobody discovers a new one hiding in row 6,214.
The Key That Makes a Row Findable
Every table needs one column, or a short combination of columns, that no two rows ever share.
g) This is called primary key. A firm-issued client code is a primary key candidate; a trade name is not, because Varun found three spellings of the same client under three different names. A key does not care about spelling. It only cares that the value is unique and never blank.
Once a key exists, a row can be pointed to instead of copied.
h) This single idea is the technical version of what CA Kapoor discovered at K&D: the difference between six copies of a Trial Balance and one Trial Balance that six people are permitted to look at.
How Tables Talk to Each Other
A real business is never one table.
i) Shakti needs a table of materials, a table of customers, and a table of dispatches, and a dispatch is only useful once it can say which customer and which material it belongs to. A foreign key is a column in one table that holds the primary key of a row in another table — nothing more exotic than a pointer.
This is what “linked back to those same underlying figures, not a copy of them” meant in Episode 8.
j) A workpaper does not carry the Trial Balance inside itself. It carries a pointer to it. Change the Trial Balance once, and every workpaper pointing to it sees the change instantly, because there was only ever one copy to change.
Foreign keys are also what stop a dispatch from referring to a customer that does not exist.
k) The database refuses the entry outright, at the moment it is typed, rather than letting the mismatch surface three weeks later during reconciliation.
The Promise No One Sees (Constraints)
A constraint is a rule the table itself enforces, so that no person has to remember to enforce it.
l) “This column may never be blank.” “This amount may never be negative.” “This GSTIN must be exactly fifteen characters.” Ravi’s insistence on one name for one material is, in spirit, a constraint — the database version simply cannot be argued around at 6 p.m. on a busy day the way a person sometimes can.
A constraint fails loudly, at the moment of entry, not quietly, at the moment of reconciliation.
m) This is the entire difference between catching an error the second it is made and discovering it, as Farah’s team did, two weeks later while comparing two exports pulled on different dates.
The Moment Two People Touch the Same Row
A database is built for many hands at once, and this creates a question Excel never has to answer:
n) What happens when two people try to change the same row in the same instant? A database wraps every change in something called a transaction — a small bundle of work that either completes entirely or does not happen at all. There is no state in between where half a change has landed.
While one transaction is in progress, the database quietly holds that row so a second transaction cannot collide with it mid-change.
o) This is not bureaucracy for its own sake. It is the technical reason two articled students updating the same client file, at the same moment, cannot silently overwrite one another the way two people saving the same Excel file eventually do.
This guarantee has a name — ACID — but the name matters less than the promise:
p) a change either fully happens, is never left half-done, does not interfere with any other change happening at the same time, and, once confirmed, survives even if the machine loses power a second later.
Why Answers Arrive Instantly
Without help, finding one row among a million means reading all of them, one at a time.
q) An index is a separate, smaller structure the database maintains on the side — sorted, quick to search — that points straight to the row being asked for, the way a book’s index points to a page instead of asking the reader to turn every one.
An index is not free.
r) It speeds up finding a row, and it adds a small amount of work every time a row is added or changed, because the index must be kept current too. This is why indexes are placed deliberately, on the columns actually searched by often, and not scattered across every column out of habit.
Who Is Allowed to See What
A database can tell people apart.
s) Some are allowed only to look. Some are allowed to add new rows but not change old ones. Some are allowed to change anything. This is the technical shape of what K&D built when it recorded a manager’s review and a partner’s sign-off “against the file itself, with a timestamp, not scattered across email threads.” A permission and a review trail are two names for the same underlying idea: the database itself remembers who was allowed to do what, and who actually did it.
What Happens If Something Goes Wrong
A database keeps a running record of every change, separate from the data itself, before the change is confirmed.
t) If the machine crashes mid-change, this record is how the database returns, on restart, to the last fully-completed state — nothing half-written, nothing lost that had already been confirmed.
A backup is a different promise: a full copy of the data, taken on a schedule, kept somewhere else entirely.
u) A running record protects against a crash in the next second. A backup protects against a mistake, a disaster, or a decision made in error six weeks ago that only became obvious today.
Closing Line
v) None of the above depends on which particular database an office eventually chooses. The terminology may differ slightly but not the ideas. Following is an illustrative list thereof.
1) a declared shape,
2) a key that makes a row findable,
3) a pointer instead of a copy,
4) a rule enforced without being asked twice,
5) a change that fully happens or not at all,
6) an index for speed,
7) a permission for trust,
8) a record kept for the day something goes wrong —
Appendix-2: Codifying requirements in the context of a database
a) Before dwelling upon this subject, it may be prudent to take note of the fact that Microsoft itself is bringing many characteristics of a database into ‘Excel’ like ‘REGEXTEST, REGEXEXTRACT, REGEXREPLACE’ feature.
b) Today, almost all the popular databases come with a Graphic User Interface, among other conveniences. Typing out commands line by line, the way it was once done, is no longer the only way in. Screens, menus, and forms now sit on top of most of them, the same way a dashboard sits on top of a car’s engine. This one change is why the decision in front of you is smaller than it may feel.
Every office reading this has already used a Graphic User Interface — Excel itself is one.
c) Building an XLOOKUP or a VLOOKUP is not typing raw computer instructions. It is clicking a cell, selecting a range with the mouse, choosing a function from a dropdown, or typing a formula into a familiar grid of boxes. That grid, those dropdowns, the ribbon along the top — the entire visible, clickable layer — is the Graphic User Interface. Underneath it, Excel is doing more exact, mechanical work than what was actually typed; the office simply never has to see that part.
A database’s screen does the same job, the same way, for the same reason.
d) Where a formula bar has someone typing a lookup by hand, a database screen more often gives a form — pick “Customer” from a list, and the matching details simply appear. The lookup still happens; nobody has to write it out.
Where a formula gets dragged down a column, a database repeats the match for every row on its own-:
e) The relationship between two tables — the database’s version of two linked sheets — was set up once, not re-typed for every new entry the way a dragged VLOOKUP quietly has to be.
How a formula works
f) Where a formula points to a cell reference like a range on another sheet, a database screen shows a linked table by name — Customers, Invoices — and lets someone click between them, much the way one clicks between sheet tabs at the bottom of a workbook.
The honest difference is not how the screen looks; plenty of database screens look as plain as Excel’s own grid.
g) The difference sits behind the screen. A VLOOKUP can quietly return the wrong answer the moment a row shifts or a range was never updated, and nothing in Excel stops it. The database version of the same lookup — the foreign key, covered a few pages on — is enforced by the structure itself, so it cannot silently point to the wrong row the way a dragged formula sometimes does.
What a Serious Database Actually Offers
h) It helps to know, in plain terms, what a serious database actually offers today, beyond simply doing the lookup more safely.
i) No product is named anywhere in this chapter — the capabilities below are common to the credible, widely-used databases an office is likely to end up choosing between.
It holds more than plain numbers and text.
j) Dates, whole numbers, decimals with exact precision (the kind an accountant, not a scientist, needs), long descriptions, and increasingly, structured data such as an entire JSON document, a list of values in one cell, or a physical location — all as native, checked types, not text pretending to be something else.
It enforces data integrity without being asked twice.
k) A column can be told to never accept a blank value, a value can be told to never repeat, and one table can be told to only ever point to rows that genuinely exist in another — this last one is the foreign key mentioned above, the database’s answer to a VLOOKUP that silently points at the wrong row. These promises hold even when ten people are entering data at the same time, and even when the person entering data has no idea the rule exists.
It handles many people at once, correctly, and still stays fast.
l) This is the concurrency promise from the appendix — many hands, one current answer — paired with the machinery that keeps it quick: structures that let the database jump straight to a row instead of scanning every one, and a query planner that quietly chooses the fastest route to an answer, the way an experienced clerk knows which drawer to open first.
It protects itself against disaster, not just against being asked politely.
m) A running log of every change, kept separately, means the database can recover to the exact moment before a crash. Beyond that, a live standby copy — a second, constantly-updated version of the data sitting elsewhere — means a single machine failing does not mean the office’s records fail with it.
It controls, in detail, who is allowed to do what.
n) Not just “can log in” or “cannot,” but who may only read a table, who may add to it, who may see certain columns but not others (useful when one column is a salary), and who may change nothing at all without it being recorded against their name.
It can be taught new tricks without being rebuilt.
o) An office can add its own custom calculations, its own step-by-step procedures, and its own automatic reactions to events — a stock level dropping below a threshold, a due date passing — as living, updatable pieces of the database itself, not a separate program bolted on the side.
It works comfortably in more than one language and script, and can search meaning, not just spelling.
p) Devanagari, Gujarati, or Tamil text sits in the database exactly as safely as English does, and a well-set-up database can search “overdue receivable” and correctly ignore trivial differences in spelling or word order — something a spreadsheet’s Ctrl+F was never built to do.
Actual Implementation. Do it yourself or outsource it.
Path One: Do It Yourself
q) This path suits Anna’s scale and the early part of Shakti’s i.e., typically for a smaller team.
1) A single owner, or a small team, learning enough of one tool — through its screens and forms, not through typed commands — to hold a few related tables and pull a handful of answers a spreadsheet was struggling to give.
Nobody needs all seven capabilities above on day one.
2) A first attempt reasonably uses perhaps two of them — a couple of sensible data types, and a rule or two that stops bad data from being entered. The rest exist for later, the way a car’s cruise control exists for a highway trip a new driver isn’t taking yet.
The learning curve is real but no longer steep.
3) A person comfortable in Excel — formulas, filters, a pivot table or two — is already most of the way there. The unfamiliar part is not typing; it is the handful of ideas covered in the appendix and above: a table’s shape is declared, not drawn freehand; a key keeps rows unique; two tables connect by a shared key instead of a copied column.
Free trials, free tiers, and free tools are widely available.
4) Nobody needs to spend money to find out whether this path is comfortable. A weekend spent building one small table, for one real question the office actually asks every week, tells you more than a month of reading.
The honest limit of this path is time, not intelligence.
5) A working owner or manager already has a full day. Learning a new tool alongside that day happens slowly, in stolen hours, and a firm in a hurry should expect this path to take longer than the second one, not because it is harder, but because it competes with everything else on the same calendar.
Path Two: Bring in Someone for the Hand-Holding
r) Just because you are hiring another person, your responsibilities are in no manner reduced.
1) The person hired sets up the tables, gets the first few screens working, decides which of the seven capabilities above the office actually needs now versus later — and, this is the part worth insisting on — teaches the office’s own people to use and maintain what has been built. A good hire leaves the office more capable than was found. The poor one leaves the office permanently dependent on being called back for even small changes.
Look for someone who asks about business before asking about the technology.
2) Rajesh’s question to Iqbal was not “which database should we buy” — it was three specific decisions the departments make every day, and the exact question each one needs answered. The right person for hire asks the same kind of question first. Anyone who proposes a solution before understanding what Quality, Finance, and Dispatch actually need each morning is skipping the only step that matters.
Ask to see something they have built before, and ask who maintains it now.
3) If the honest answer is “I still do, for every client I’ve ever built one for,” that person builds dependency, not capability, whatever else they say in the meeting.
A short, bounded engagement is healthier than an open-ended one.
4) “Build this one thing, train two of our people on it, and be available for questions for one month after” is a request with an end. “Come and help us with our data” is not, and tends to cost more than either side expected.
Choosing Between the Two
s) The status of a database in respect of all three is as follows. Following are three simple rules.
i. A single, well-defined need points toward doing it yourself.
ii. Several teams, several related tables, and a need for other people to trust the answer without re-checking those points toward hiring the handholding.
iii. Either path can be tried and abandoned cheaply, and that is the real point.
Whichever Path Is Chosen — Start Small
Begin with one question, not one system.
1) Nothing here is marriage. A weekend spent building one small table costs a weekend. A one-month bounded engagement costs one month. The expensive mistake is not choosing wrong — it is choosing nothing, for another two years, while the six-copy Trial Balance problem quietly repeats itself.
2) Draft your requirements in absolute terms. Do not enter into the sphere as to how a database will work or works.
For example, “give us one place where the receivable balance is always current”, for one client, refreshed automatically.” A small, real success is what earns the next one the budget and the trust to happen.
Resist the temptation to move every spreadsheet in the office on day one.
3) Shakti did not replace SAP; it asked SAP three new questions.
4) K&D did not digitise every process at once; it solved the one problem — six copies of one Trial Balance — that had already cost it a near-miss.
Whichever path is chosen, the office is not choosing a product yet.
5) It is choosing who will do the learning — the office’s own people, or someone hired to teach them — and how big a first bite to take. Both are answerable this month, without a single product name entering the conversation.
Appendix-3: Translating the Stories into real life
a) The fact that you are reading this means you are convinced that your office needs a database in addition to various spreadsheets.
A few names
b) Popular licensed databases are like SAP/Hana, Oracle being extremely powerful. Can handle data say that of a stock exchange, bankers etc.
c) Tally also stores the data in a database only. Access is available through TDL (Tally Development Language)
d) There are equally powerful free databases like PostgreSQL, MariaDB etc.
| Database | Key Features | Generally Prominent Domain |
| PostgreSQL | ACID-compliant, extensible (custom types, extensions like PostGIS, pgvector), strong JSON support, MVCC concurrency | General-purpose OLTP, fintech, audit/compliance systems, geospatial apps |
| MySQL / MariaDB | Fast reads, replication, widely supported, simpler feature set than Postgres | Web applications, CMS platforms (WordPress), e-commerce |
| Redis | In-memory, sub-millisecond latency, pub/sub, data structures (lists, sets, sorted sets) | Caching, session stores, real-time leaderboards, rate limiting |
| HBase | Built on Hadoop/HDFS, strong consistency, column families | Big data batch + random access workloads |
e) We will be restricting ourselves to the cases of
a. Shakti Precision and
b. K & D Associates.
f) We will be taking one example for each of above.
Defining the requirements-:
| a) The data that we aspire to capture, and process is static and historic.
b) Majority of the data might be getting imported into the database, some entries may be made manually. c) There is essentially a HIL (Human in loop) It means that there is no automation for executing any major decision and a human is there in the loop who applies wisdom. |
d) The users are well versed with Excel (spreadsheet).
e) When an entity will get database, they will get utilities to import data from excel. |
a) The data that we aspire to capture, and process is static and historic.
b) Majority of the data might be getting imported into the database, some entries may be made manually.
c) There is essentially a HIL (Human in loop) It means that there is no automation for executing any major decision and a human is there in the loop who applies wisdom.
d) The users are well versed with Excel (spreadsheet).
e) When an entity will get database, they will get utilities to import data from excel.
Shakti Precision
g) The company engaged a person to automate the last mile connectivity that was not provided by SAP. SAP ability is not a problem, the cost of doing through SAP is….
| Step | Current Process (Excel-based) | Future Process (Database + Automation) |
| 1. Receive Import Documents | The supplier sends the Commercial Invoice, Packing List and other import documents as PDF files through email. | The supplier’s documents are uploaded into the Import Management System or received automatically through an integration. |
| 2. Extract Item Details | The executive manually copies the inventory item description, quantity, value and other details from the PDF invoice into an Excel sheet. | The system automatically extracts item description, HSN code, quantity, invoice value, currency and other relevant fields using OCR and AI-assisted document processing. |
| 3. Identify the Inventory Item | The executive manually searches the Item Master or relies on experience to identify the corresponding inventory item. | The system matches the imported item with the Item Master using item description, supplier history, HSN code and previous imports. Possible matches are suggested automatically. |
| 4. Determine Applicable Duty Rate | Using VLOOKUP/XLOOKUP, the executive searches the Import Duty Chart maintained in Excel to determine the applicable customs duty rates. | The system automatically identifies the applicable Basic Customs Duty, Social Welfare Surcharge, IGST, Anti-Dumping Duty and other applicable levies from the Duty Master database. |
| 5. Calculate Import Duty | The executive manually prepares Excel formulas to calculate various import duties and verifies the calculations. | The system automatically calculates all duties using predefined business rules and maintains a complete calculation trail. |
| 6. Receive C&F Working | The Clearing & Forwarding Agent emails duty calculations and supporting documents in PDF or Excel format. | The C&F Agent uploads the duty working directly into the system or the data is received electronically through an interface. |
| 7. Verify C&F CalculationsStep | The executive manually compares every duty component in the C&F working with the Excel calculations prepared internally.
Current Process (Excel-based) |
The system automatically compares the C&F Agent’s calculations with internally computed values and highlights only the differences requiring review.
Future Process (Database + Automation) |
| 8. Verify Bill of Entry | After Customs issues the Bill of Entry (PDF), the executive manually compares quantities, HSN codes, assessable value, exchange rate and duty amounts with the Excel working. | The Bill of Entry is uploaded into the system. Relevant fields are extracted automatically and reconciled with the Purchase Order, Supplier Invoice, Duty Calculation and C&F Working. |
| 9. Investigate Exceptions | Every mismatch is manually identified and investigated by reading multiple PDF documents and Excel sheets. | Only exceptions identified by the system are presented to the executive, along with the supporting documents required for investigation. |
| 10. Correct Errors | Corrections are made manually in Excel. Revised versions of the spreadsheet are created and shared through email. | Approved corrections are recorded directly in the system with complete user, date and time audit trails. No duplicate working files are created. |
| 11. Obtain Approval | The Excel working and supporting documents are emailed to managers for approval. Multiple versions often circulate before final approval. | The workflow routes the transaction electronically to the appropriate approver. Every approval, rejection and remark becomes part of the transaction history. |
| 12. Store Documents | Supplier Invoice, C&F Working, Bill of Entry and Excel workings are stored in multiple folders with names such as Import_Duty_Final.xlsx or Final_v3.xlsx. | Every document is permanently linked to the same import transaction. Users can retrieve all related documents from a single screen. |
| 13. Audit & Future Reference | During audit, staff search emails, folders, PDFs and Excel files to explain how the duty was calculated. | During audit, opening the import transaction immediately displays the complete history—documents, calculations, approvals, corrections and audit trail—without searching multiple locations. |
K & D Associates
h) A database does not replace professional expertise. It removes the friction that prevents professionals from applying that expertise effectively.
| Step | Today – Excel-based Audit | Tomorrow – Database-based Audit |
| 1. Engagement Acceptance | CA Kapoor accepts the audit. An engagement folder is created. Several Excel trackers are prepared manually. | CA Kapoor accepts the audit. The system creates a unique Engagement ID. Everything is linked to this engagement. |
| 2. Team Allocation | CA Deshmukh emails the team. Manish updates Team Allocation.xlsx. | CA Deshmukh assigns the team in the system. Everyone immediately sees the engagement in their dashboard. |
| 3. Trial Balance | Aditi downloads the Trial Balance from Tally and saves TB_Final.xlsx. Later, TB_Final_Updated.xlsx appears. | Aditi imports the Trial Balance into the engagement. Every workpaper uses the same Trial Balance. |
| 4. Lead Schedules | Aditi prepares Lead Schedule.xlsx. Formula changes have to be copied manually whenever the Trial Balance changes. | Lead schedules are generated from the imported Trial Balance. Any approved revision updates every linked schedule automatically. |
| 5. Stock Verification | Priya prepares Stock Verification.xlsx. Photographs are stored separately in folders. | Priya records observations directly in the engagement. Photographs are attached to each observation. |
| 6. Purchase Vouching | Kunal records exceptions in Purchase Vouching.xlsx. Manager receives updates only after the file is shared. | Kunal creates audit observations directly. Manish sees them instantly. |
| 7. Bank Reconciliation | Neha emails Bank Reconciliation.xlsx to Farah for review. | Neha marks the workpaper Ready for Review. Farah reviews it online. |
| 8. Fixed Asset Verification | Varun prepares another Excel and emails it. | Varun completes the workpaper. It automatically appears in the pending review queue. |
| 9. Audit Queries | Manish maintains Pending Audit Queries.xlsx. Status is updated manually. | Queries are raised within the engagement. Status changes from Open → Client Responded → Closed automatically as work progresses. |
| 10. Client Documents | Client sends documents through email, WhatsApp, shared drives and pen drives. Staff save them in different folders. | Client uploads documents against the relevant audit query or workpaper. Every document is linked to the engagement. |
| 11. Review Notes | Farah marks comments in Excel or PDF. Different versions circulate by email. | Farah records review comments directly against the workpaper. Resolution history is permanently preserved. |
| 12. Partner Review | CA Kapoor asks for the latest files. Staff search folders and email attachments. | CA Kapoor opens the engagement dashboard. Every pending observation, review note and document is available instantly. |
| 13. Status Monitoring | Multiple Excel trackers maintained by different people. Consolidation is manual. | Live dashboard shows planning, fieldwork, review, pending queries, due dates and workload. |
| 14. Searching Information | Staff search Outlook, Windows folders, WhatsApp, shared drives and multiple Excel files. | Search once. Every workpaper, observation, document and communication is linked to the engagement. |
| 15. Version Control | TB_Final.xlsx, TB_Final_v2.xlsx, Final_Final.xlsx, Latest_Final.xlsx… | One engagement. One version of every workpaper. Complete revision history is preserved automatically. |
| 16. Knowledge Retention | Much knowledge remains in the minds of Priya, Manish or Farah. Staff leaving the firm often means losing context. | Knowledge belongs to the engagement. Anyone joining later can understand the complete history from the system. |
| 17. Partner’s Question | “Show me all unresolved inventory observations.” Staff begin searching multiple Excel files. | CA Kapoor filters Inventory Observations → Status = Open. Results appear in seconds. |
| 18. Audit Completion | Files are copied into a Final folder. Future retrieval depends on folder structure and file names. | Engagement is marked Completed. Every workpaper, document, review note and conclusion remains permanently linked and searchable. |
Author Bio
