your bookkeeping
One row per transaction
Have you ever tried to set up your bookkeeping in Coda? To finally get a grip on your revenues and expenses, all in one place.
If you have, your first instinct was probably to set it up just like in Excel: a column for “Date,” a column for “Description,” maybe a column for “Revenues,” and another for “Expenses.” It feels natural, right? It’s the way most of us were taught to think about money.
This is what I call “spreadsheet bias.” It’s a habit that is perfectly fine for simple lists, but in Coda, it’s a trap. It creates a data dead-end.
The moment you want to ask a simple question, your doc will fight you. How do you get a clean total for a specific client? Or sum up all your “Software” expenses? You can’t, not easily. Your data is stuck in those two separate “in” and “out” columns.
This blog is for you. It’s for everyone who is ready to break that old habit. We’re going to explore the database way of organizing your finances, which is built on one simple, powerful rule: one row per transaction.
It might feel a little different at first, but I’ll show you why this single shift in thinking is the secret to building a financial doc that is fast, flexible, and infinitely more powerful.
Building Your Core Transaction Table
We’re going to create one single, central table for everything. We’ll call it [DB Transactions].
That “DB” prefix is intentional and important. It constantly reminds us that we’re treating this as a proper database, not just a list. And just as importantly, it signifies that this is our base table — the single source of truth from which all our views, charts, and forms will eventually be built.
This is where we break the old habit for good. Instead of those separate “Revenue” and “Expense” columns, you’ll use just two simple ones: an Amount column for the value and a relation column called Transaction Type that links to a simple helper table (e.g., [Transaction Types]) which contains "Revenue" and "Expense" as its row objects. This simple shift is the key. Calculating your profit now becomes a single, clean formula: just sum all your "Revenue" amounts and subtract all your "Expense" amounts. Your data is finally flexible.
From this core [DB Transactions] table, you build out the context by adding columns for all the properties that describe the transaction. This includes the essentials, like the Date it happened and the Currency it was paid in (which is vital for converting everything back to your main asset, like Euros or Dollars). We'll apply the same relation logic for Payment Type. Instead of a static select list, you'll create a relation to a [Payment Types] helper table that holds "Prepayment," "Partial Payment," and "Full Payment" as its objects. This makes your doc scalable, allowing you to add new payment statuses later without ever having to edit your main table's column settings.
Then, you add the “who” and “what” by creating relations to your other core tables. This is the modern Coda way: you’ll add a relation column that links to your [Clients] table and another that links to your [Contacts] table. You'll do the same for categorization, with relation columns for [Category] and [Sub-Category]. You're no longer just pulling in text; you're connecting to the actual row objects from those tables, which is what lets you use powerful formulas like Filter on them later. A Notes column can catch any other details that don't fit elsewhere.
Now, this setup leads to the real “aha!” moment. You might be thinking, “This is great, but what about tracking projects?”
In the old spreadsheet model, this would be a nightmare. You’d have to add complex columns or start a new sheet, and nothing would link together.
Here, in our [DB Transactions] table, you just add one new relation column called Project that links directly to your [Projects] table.
Instantly, you’ve unlocked an entirely new dimension in your data.
You can now go to any project in your [Projects] table (which is now a collection of objects) and see its exact, real-time profitability. You can write a formula to Filter your [DB Transactions] table based on a specific project. This is why we ditch the spreadsheet bias. You're no longer building a static list; you're building a relational database. You can add any relation you want to track—Project, Team, or Sales Region—and your data just gets richer and more powerful with every connection you make.
Views: Your Windows to the Data
Now that we have our powerful [DB Transactions] table, it's helpful to think about its role. My personal approach is to treat this base table as the single source of truth—the one place all my data lives. I find it's best to almost never work directly in it. Instead, I build all my workflows on top of it using Views. This separation is what makes the whole system feel so clean and manageable.
What is a view?
A view is not a copy of your table. It’s a live, interactive interface that you build to look at, filter, and work with the data in your base table. This is where you build your “app,” and Coda gives you many different types of views for different jobs.
For example, your first step is to create a Form view. This becomes your “Add New Expense” or “Log New Revenue” page. It’s a beautiful, clean interface that ensures you and your team can safely add new rows to the [DB Transactions] table without ever seeing or touching the complex base table itself.
Then, you’ll want to see your data. You can create a classic Table view and add a filter where Transaction Type is "Expense" to create a clean "All Expenses" ledger.
But you’re not limited to a table. You can add a Chart view that looks at that exact same data to create a “Monthly Revenue” bar chart or a “Spend by Category” pie chart. This is your analytics dashboard.
Want to track your invoice pipeline? Create a Board view (like a Kanban) and group it by your Payment Type relation. You'll instantly get columns for "Pending," "Partial Payment," and "Full Payment." You can literally drag a transaction card from one column to the next, and you are live updating the row in your base table.
Need to see what’s due? Add a Calendar view that plots all your transactions by their Date. Or create a Card view to see a visual gallery of "Unpaid Invoices" for each client.
This is the crucial distinction: that Board, that Chart, that Calendar, that Form, and that filtered Table are all just different windows looking at the exact same rows in your one [DB Transactions] table. Fill out the Form, and a new row appears in the base table, which instantly updates your Chart. Drag a card on the Board, and the status changes in the base table. That is the power of separating your data (the base table) from its presentation (the views).
Buttons: Your One-Click Actions
As your doc grows, your [DB Transactions] table might eventually have thousands of rows. While Coda is powerful, loading all that data every day can make your doc feel sluggish. You don't want to delete old records—that's your financial history! But you don't necessarily need transactions from two years ago in your "live" table.
This is a perfect job for a Button. You can create a second table, perhaps called [DB Archive], that has the exact same column structure as your [DB Transactions] table. Then, you place a button on your page called "Archive Old Transactions."
This button’s action will be a formula that first Filters your [DB Transactions] table to find all the rows that are "played out"—for example, their Payment Type is "Full Payment" AND their Date is older than one year. The button will then copy all those rows over to the [DB Archive] table, and once they are safely copied, it will delete them from the main [DB Transactions] table.
With one click, you’ve just moved all that old data to a safe, long-term storage table, keeping your main [DB Transactions] table lean, fast, and focused on what's relevant today.
It’s a Mindset, Not Just a Table
This journey from “spreadsheet bias” to a true “database way” of thinking is the single most important step you can take in . It might feel like a little more setup at the beginning, but believe me, it pays off.
Your [DB Transactions] table is a single source of truth that you can connect to anything. You can build all those powerful views—charts, boards, and forms—knowing they're all in perfect sync. You can track projects, clients, and categories in a way that's simply impossible when your data is trapped in separate columns.
And this foundation is exactly what we’ll need for our next challenge. In our next post, we’ll explore the logic of prepayments. What happens when a client pays a significant amount upfront to cover future expenses? It’s great for cash flow, but how do you keep track of their remaining budget in Coda as you log new transactions against it? We’ll build the logic for that right on top of the [DB Transactions] table we designed today.
On a personal note, creating these in-depth posts takes a lot of time and effort. While I love sharing my knowledge, a little support goes a long way. If you found this helpful, what about a donation and sharing this post with your fellow Coda enthusiasts? Every bit of encouragement helps!
My name is Christiaan, and I regularly blog about Coda. While this article is free, my professional services (including consultations) are not, but I’m always happy to chat and explore potential solutions. You can find my free contributions in the Coda Community and on X. The Coda Community is a fantastic resource for free insights, especially when you share a sample doc.
