Fintech is one of the most interesting domains in tech, yet there's surprisingly little beginner-friendly content for developers looking to get started. At its core, FinTech combines traditional finance and accounting knowledge with software engineering to build scalable financial tools.
You might be wondering: if it's "FinTech" (Financial Technology), why are we learning about accounting instead of finance? Good question. Let me explain.
Finance vs. Accounting
Finance and Accounting are related but different fields.
Accounting is about recording and reporting financial transactions. This includes preparing the three core financial statements: the Income Statement (or Profit & Loss Statement), the Balance Sheet, and the Cash Flow Statement. It gives you a historical view of a company's financial performance at a specific point in time. It's essential for compliance and forms the foundation for financial analysis.
Finance is broader. It involves managing money and making strategic decisions based on accounting data. Finance activities include investing, borrowing, lending, budgeting, and forecasting. While accounting looks backward, finance looks forward - using past data to make decisions about future projects, resource allocation, and profitability.
The key point is that understanding finance requires foundational knowledge of accounting, as accounting data is the basis for financial decision-making.
Bookkeeping vs. Accounting
Another term you'll hear is Bookkeeping. While related to accounting, they serve different purposes.
| Bookkeeping | Accounting |
|---|---|
| Recording financial transactions | Summarizing and analyzing financial data |
| Posting debits and credits | Preparing financial statements |
| Reconciling bank statements | Analyzing operational costs |
| Processing accounts payable/receivable | Completing tax returns |
| Maintaining ledgers and accounts | Advising on financial decisions |
Bookkeeping focuses on maintaining accurate records. Accounting focuses on interpreting those records to produce financial statements and actionable insights.
What Are Financial Models?
A Financial Model is a tool used to forecast a business's financial performance. Models perform calculations and generate recommendations based on that analysis.
Common uses include:
Business valuation
Financial planning and budgeting
Forecasting
Investment analysis
Raising capital
This guide focuses on Accounting, teaching you the fundamentals needed to build software that records and reports financial transactions.
What is Accounting?
Accounting is the systematic process of recording, categorizing, and reporting financial transactions. Its purpose is to provide a clear and accurate picture of an entity's economic activities.
Key Aspects of Accounting
Recording Transactions: The fundamental step where every financial transaction is documented. These records form the basis for everything else.
Classifying Transactions: Transactions are categorized into accounts like sales revenue, expenses, assets, liabilities, and equity.
Preparing Financial Statements: Transaction data is used to prepare the Income Statement, Balance Sheet, and Cash Flow Statement.
Auditing and Compliance: Ensuring records are accurate and comply with legal, regulatory, and tax requirements.
Analysis and Advisory: Analyzing financial data to understand performance, identify trends, and provide recommendations.
Budgeting and Forecasting: Preparing budgets and forecasts to help businesses plan.
Accounting is essential not just for businesses but also for individuals, non-profits, and government organizations.
The Accounting Equation
The foundation of all accounting is this equation:
Assets = Liabilities + Equity
This equation must always balance. Every transaction affects at least two accounts in a way that maintains this equality. This is the basis of double-entry bookkeeping.
Double-Entry Bookkeeping
Double-entry bookkeeping is the standard system where every transaction is recorded in at least two accounts:
One account is debited
Another account is credited
Total debits must always equal total credits
This provides built-in error checking and creates a complete audit trail.
Example: When a company receives $1,000 cash from a customer:
Debit Cash (Asset): $1,000 (increases)
Credit Accounts Receivable (Asset): $1,000 (decreases)
Accounts: The Building Blocks
An account is a record in the General Ledger used to collect and store debit and credit amounts. Following the double-entry principle, every transaction affects at least two accounts.
Types of Accounts
| Account Type | Normal Balance | Examples |
|---|---|---|
| Assets (Dr.) | Debit | Cash, inventory, property/plant/equipment, patents |
| Liabilities (Cr.) | Credit | Loans, accounts payable, mortgages, deferred revenue |
| Equity (Cr.) | Credit | Share capital, retained earnings, additional paid-in capital |
| Revenue (Cr.) | Credit | Sales revenue, service revenue, interest income |
| Expenses (Dr.) | Debit | Cost of goods sold, salaries, rent, utilities |
How Debits and Credits Affect Accounts
| Account Type | Increased by | Decreased by |
|---|---|---|
| Assets | Debit | Credit |
| Liabilities | Credit | Debit |
| Equity | Credit | Debit |
| Revenue | Credit | Debit |
| Expenses | Debit | Credit |
These account types appear on their respective sides of the General Ledger (GL) - debits on the left, credits on the right.
Contra Accounts
Contra accounts are special accounts used to offset the balance of a related account. They carry opposite balances to their paired accounts.
Think of them as mechanisms that partially reverse the effects of another account, reducing its reported value on financial statements.
Characteristics:
Opposite Balance: If the related account has a debit balance, the contra has a credit balance (and vice versa)
Paired with Specific Accounts: Always linked to and offsets a specific account
Net Reporting: Displayed as a single net amount on financial statements
Common Contra Accounts
| Contra Account | Paired With | Purpose |
|---|---|---|
| Accumulated Depreciation | Property, Plant & Equipment | Records total depreciation over time |
| Allowance for Doubtful Accounts | Accounts Receivable | Estimates uncollectible receivables |
| Sales Returns and Allowances | Sales Revenue | Records returned goods or post-sale allowances |
Example: A company buys a machine for $10,000 that depreciates by $1,000 annually. The accumulated depreciation account will show a credit balance of $1,000 after year one, $2,000 after year two, and so on.
Debits and Credits
Debit (Dr.): An entry on the left side of an account. Increases asset and expense accounts; decreases liability, equity, and revenue accounts.
Credit (Cr.): An entry on the right side of an account. Increases liability, equity, and revenue accounts; decreases asset and expense accounts.
Journal Entries
A journal entry is the record of a financial transaction before it's posted to the General Ledger. They're recorded in chronological order in the General Journal.
Each journal entry includes:
Date of the transaction
Accounts affected (debited and credited)
Amounts
Description explaining the transaction
Example:
The General Ledger (GL)
The General Ledger is the master record of all financial transactions within an organization. It's the central repository for accounting data from all sub-ledgers and journals (sales journal, purchases journal, cash receipts journal, etc.).
A GL contains:
Individual accounts are organized by the Chart of Accounts
Transaction details (date, description, amount)
Debit and credit entries
Chart of Accounts
The Chart of Accounts (COA) is the master list of all accounts used by an organization, organized by category. It provides a standardized numbering system.
Typical structure:
| Account Range | Category |
|---|---|
| 1000-1999 | Assets |
| 2000-2999 | Liabilities |
| 3000-3999 | Equity |
| 4000-4999 | Revenue |
| 5000-5999 | Cost of Goods Sold |
| 6000-6999 | Operating Expenses |
The COA is one of the first things you'll design when building accounting software.
Trial Balance
A Trial Balance is a report that lists all General Ledger accounts and their balances at a specific point in time. Its purpose is to verify that total debits equal total credits.
If the Trial Balance doesn't balance, there's an error somewhere that must be found and corrected before preparing financial statements.
Fiscal Year and Accounting Periods
A fiscal year is the 12-month period a company uses for accounting and financial reporting. Unlike a calendar year (January-December), a fiscal year can start on any date.
Common examples:
US Federal Government: October 1 - September 30
Many retail companies: February 1 - January 31 (to capture the holiday season)
UK companies: April 1 - March 31
Accounting periods are the intervals at which financial statements are prepared - typically monthly, quarterly, or annually.
Accrual vs. Cash Basis Accounting
Understanding when to recognize revenue and expenses is critical for building payment systems.
| Aspect | Cash Basis | Accrual Basis |
|---|---|---|
| Revenue recognized | When cash is received | When earned (regardless of payment) |
| Expenses recognized | When cash is paid | When incurred (regardless of payment) |
| Complexity | Simple | More complex |
| Best for | Small businesses | Most FinTech applications |
| GAAP/IFRS compliant | No | Yes |
Example with a Subscription Service:
Customer pays $120 on January 1 for a 12-month subscription
Cash basis: Record $120 revenue in January
Accrual basis: Record $10 revenue each month (earned as service is provided)
For developers, this means your system needs to track both when money moves AND when revenue/expenses are recognized. These are often different events.
Immutable Ledgers and Audit Trails
In FinTech, you never update or delete a financial transaction. This is non-negotiable for regulatory compliance and auditability.
The rules:
Transactions are immutable - once recorded, they cannot be modified
Corrections are reversals - to fix an error, create a reversing entry, then create the correct entry
Everything is timestamped - record who did what, when
Soft deletes only - mark records as deleted, never actually delete them
Reversal Pattern
Instead of updating a wrong entry, you create a reversal:
Original (Wrong):
Jan 15: Debit Office Supplies $500, Credit Cash $500
Reversal:
Jan 16: Debit Cash $500, Credit Office Supplies $500
Correcting Entry:
Jan 16: Debit Office Equipment $500, Credit Cash $500
For developers: your database schema should NOT allow UPDATE or DELETE on transaction tables. Build your APIs to only INSERT.
Common FinTech Transactions
Here's how everyday FinTech operations translate to journal entries:
Customer Deposits Money into Wallet
Debit: Bank Account (Asset) $100
Credit: Customer Wallet Liability $100
The money is in your bank, but you owe it to the customer.
Customer Withdraws Money
Debit: Customer Wallet Liability $50
Credit: Bank Account (Asset) $50
Transfer Between Users (User A to User B)
Debit: User A Wallet Liability $25
Credit: User B Wallet Liability $25
No real money moved - just updated who you owe.
Platform Charges a Transaction Fee
Debit: Customer Wallet Liability $1
Credit: Fee Revenue (Revenue) $1
Customer Requests a Refund
Debit: Refunds (Contra-Revenue) $20
Credit: Customer Wallet Liability $20
Loan Disbursement
Debit: Loans Receivable (Asset) $1,000
Credit: Bank Account (Asset) $1,000
Loan Repayment (Principal + Interest)
Debit: Bank Account (Asset) $110
Credit: Loans Receivable (Asset) $100
Credit: Interest Income (Revenue) $10
From Theory to Code: Database Schema
Here's a minimal database schema for an accounting system:
Core Tables
-- Chart of Accounts
CREATE TABLE accounts (
id SERIAL PRIMARY KEY,
account_code VARCHAR(20) UNIQUE NOT NULL,
account_name VARCHAR(100) NOT NULL,
account_type VARCHAR(20) NOT NULL, -- ASSET, LIABILITY, EQUITY, REVENUE, EXPENSE
normal_balance VARCHAR(10) NOT NULL, -- DEBIT or CREDIT
parent_id INTEGER REFERENCES accounts(id),
is_active BOOLEAN DEFAULT true,
created_at TIMESTAMP DEFAULT NOW()
);
-- Journal Entries (Header)
CREATE TABLE journal_entries (
id SERIAL PRIMARY KEY,
entry_date DATE NOT NULL,
description TEXT,
reference_no VARCHAR(50),
created_by INTEGER NOT NULL,
created_at TIMESTAMP DEFAULT NOW(),
-- Immutability: no updated_at column!
is_reversed BOOLEAN DEFAULT false,
reversed_by_id INTEGER REFERENCES journal_entries(id)
);
-- Journal Entry Lines (Details)
CREATE TABLE journal_entry_lines (
id SERIAL PRIMARY KEY,
journal_entry_id INTEGER REFERENCES journal_entries(id),
account_id INTEGER REFERENCES accounts(id),
debit_amount DECIMAL(15,2) DEFAULT 0,
credit_amount DECIMAL(15,2) DEFAULT 0,
description TEXT,
-- Enforce: only debit OR credit, not both
CONSTRAINT check_debit_or_credit
CHECK (
(debit_amount > 0 AND credit_amount = 0) OR
(credit_amount > 0 AND debit_amount = 0)
)
);
-- Account Balances (Denormalized for performance)
CREATE TABLE account_balances (
id SERIAL PRIMARY KEY,
account_id INTEGER REFERENCES accounts(id),
period_date DATE NOT NULL, -- Last day of accounting period
debit_total DECIMAL(15,2) DEFAULT 0,
credit_total DECIMAL(15,2) DEFAULT 0,
balance DECIMAL(15,2) DEFAULT 0,
UNIQUE(account_id, period_date)
);
Entity Relationship
Trial Balance Query
-- Generate Trial Balance
SELECT
a.account_code,
a.account_name,
a.account_type,
SUM(jel.debit_amount) as total_debits,
SUM(jel.credit_amount) as total_credits,
SUM(jel.debit_amount) - SUM(jel.credit_amount) as balance
FROM accounts a
LEFT JOIN journal_entry_lines jel ON a.id = jel.account_id
LEFT JOIN journal_entries je ON jel.journal_entry_id = je.id
WHERE je.entry_date <= '2026-01-31' -- As of date
AND je.is_reversed = false
GROUP BY a.id, a.account_code, a.account_name, a.account_type
ORDER BY a.account_code;
-- Verify Trial Balance (should return 0)
SELECT
SUM(debit_amount) - SUM(credit_amount) as difference
FROM journal_entry_lines jel
JOIN journal_entries je ON jel.journal_entry_id = je.id
WHERE je.is_reversed = false;
The Double-Entry Constraint
Every journal entry must balance. Enforce this at the application level:
function createJournalEntry(entry: JournalEntry): void {
const totalDebits = entry.lines.reduce((sum, l) => sum + l.debitAmount, 0);
const totalCredits = entry.lines.reduce((sum, l) => sum + l.creditAmount, 0);
if (totalDebits !== totalCredits) {
throw new Error(
`Entry does not balance: Debits=${totalDebits}, Credits=${totalCredits}`
);
}
// Proceed with insert...
}
Reconciliation
Reconciliation is the process of matching your internal ledger with external statements (bank statements, payment processor reports, etc.).
Why it matters:
Detects discrepancies (fraud, errors, missing transactions)
Required for regulatory compliance
Builds trust in your financial data
Basic Reconciliation Flow
Export transactions from your ledger for a period
Import the bank statement for the same period
Match transactions (by amount, date, reference)
Investigate unmatched items
Create adjusting entries if needed
Document the reconciliation
Build reconciliation tools early. You'll need them for debugging, customer support, and audits.
Key Takeaways
| Concept | Summary | Developer Implication |
|---|---|---|
| Accounting Equation | Assets = Liabilities + Equity | Your database must always satisfy this |
| Double-Entry Bookkeeping | Every transaction affects 2+ accounts | Validate that debits = credits before saving |
| Immutable Ledger | Never update/delete transactions | Design INSERT-only transaction tables |
| Accrual Accounting | Recognize revenue when earned | Track both cash movement AND recognition dates |
| Chart of Accounts | Master list of all accounts | Design this schema first - it's your foundation |
| Trial Balance | Debits must equal credits | Build this as a data integrity health check |
| Audit Trail | Who did what, when | Log everything with timestamps and user IDs |
| Reconciliation | Match the internal ledger to external sources | Build tooling for this from day one |
What's Next?
You now have the accounting foundation needed to build FinTech software. This is Part 1 of a 6-part series. By the end, you'll have built a functional accounting system.
| Part | Topic | What You'll Build |
|---|---|---|
| 1 | Accounting Fundamentals | (this post) |
| 2 | Building Your First Ledger | Simple API with accounts and journal entries |
| 3 | Accounts Receivable (Invoicing) | Create invoices, mark as paid, and track outstanding |
| 4 | Accounts Payable (Bills) | Record bills, track what you owe |
| 5 | Bank Reconciliation | Match transactions between the ledger and bank statements |
| 6 | Financial Reports | Generate an Income Statement and Balance Sheet from your data |
Top comments (0)