Platform
One engine. Every area. No interfaces to fall out of step.
Everything below writes through the same posting code path, against the same chart of accounts, inside the same transaction. That is not an architecture diagram — it is the reason the stock report and the ledger cannot disagree.
Accounting
A real double-entry ledger
Not invoices with a report bolted on. Every movement of value in this system is a balanced voucher against a chart of accounts, which is why the trial balance is derived rather than stored — there is no second copy of the truth to drift.
Vouchers, not documents
Sales, purchase, receipt, payment, contra, journal, credit and debit note, each posting through one code path with one set of rules. A voucher that does not balance is rejected before it reaches the database — and rejected again by the database, because the constraint is not something an application bug can talk its way past.
Multi-company, kept apart
Each company keeps its own chart of accounts, numbering series, financial years and opening balances. Every query is scoped to your business, and an id that belongs to somebody else is answered as if it did not exist. Row-level security in the database adds a second lock on writes and on posting today; extending it to every read is in progress.
Cost centres, projects and budgets
Allocate a line to a cost centre or a project and see the same figure by department, project or branch. Budgets are compared against the same postings the statements use — never against a separately maintained plan.
Period close that means something
Closing a period locks it. Posting into a closed period is refused, not warned about; correcting one is an explicit reopen with a reason, recorded in the audit trail. A close that a determined user can post through is not a close.
GST
GST working papers you can defend
GST is decided at the moment a voucher is posted, from the place of supply and the parties involved — not patched onto a printed invoice afterwards. That is what makes the return data reconcile to the ledger rather than approximate it.
Place of supply drives the split
CGST and SGST or IGST is derived from the supplier state, the place of supply and the registration type, evaluated once and stored on the line. Reverse charge, exports and SEZ each take their own path, and each is covered by tests that assert the computed heads and the return figures rather than the printed label. The composition scheme is not one of those paths: you can record the registration type and print a Bill of Supply that suppresses the tax columns and carries the declaration, but choosing it changes nothing the tax engine does, and the dealer’s own turnover tax is not computed.
Working papers, per return
GSTR-1 and GSTR-3B figures and the HSN summary, assembled from the postings and broken down so every total can be traced back to the vouchers that produced it. You can hand the working paper to an accountant and they can check it — which is the whole point.
A tax invoice is checked before it gets a number
Finalising checks your GSTIN and the buyer’s against their check digits, the place of supply, an HSN or SAC code on every line, and — for an unregistered buyer on an invoice of ₹50,000 or more — the name and address Rule 46 asks for. A draft that fails says exactly what is missing and stays a draft.
E-invoicing and e-way bill, honestly
The integration is written against a provider interface with a sandbox implementation. It produces SANDBOX identifiers, the screen says so in as many words, and nothing is transmitted to any government system. When a real provider is connected it will be behind explicit consent, a confirmation screen and an idempotency key — none of which exist to be bypassed.
What it does not do
- Nothing is filed with the GST portal. There is no filing credential anywhere in this system, and no code path that would use one.
- Identifiers produced by the e-invoicing screen are marked SANDBOX and must not be issued to customers.
- There is no GSTR-2B import or matching screen yet. Purchases can be checked against orders and goods receipts, not against the portal.
- Rates and rules are configurable defaults, not tax advice. Confirm your position with your accountant.
Banking
Reconciliation you can explain line by line
Most reconciliation tools tell you a number agrees. This one tells you why, and what is left over. Every statement line is matched to an entry you confirmed, turned into an entry you approved, or still sitting in the list where you can see it.
Statements in, from the files banks give you
CSV, Excel (.xlsx), a PDF with a text layer, OFX and MT940. Import is idempotent on a content hash, so the same file loaded twice does not produce a second set of transactions, and a statement with a running balance is checked against itself before anyone relies on it.
Matches that show their working
Each line is scored against the entries already in your books — amount, reference, date, counterparty and history, out of 100 — and the score opens to show every signal. A receipt is never matched to a payment. Nothing is matched until a person confirms it.
Rules for the lines that come back
Match on narration words or a pattern, direction and an amount range, and the rule suggests the ledger and party. Rules are tried in priority order and the first that fits wins. A rule suggests; a person still saves or posts the entry.
Reconciliation that balances
Balance per the books, balance per the statement, what is in the books but not yet at the bank, what is at the bank but not yet in the books, and the difference — arranged so the arithmetic is visible. A reconciliation screen that shows only the difference is asking you to trust it.
What it does not do
- There is no bank feed. Nothing here connects to a bank’s systems and no bank credential is ever stored — statements are files you export and import.
- A scanned or photographed statement cannot be read on the banking screen, and neither can an old-style .xls file.
Inventory
Stock that agrees with the ledger
Stock and books diverge when they are two systems politely kept in step. Here a stock movement *is* a posting: the valuation layer and the ledger entry are written in the same transaction, so they cannot disagree.
Valuation that survives a reversal
FIFO or weighted average per item, held as explicit valuation layers. Reversing a movement unwinds the layers it created — which is exactly where systems that store a single running average quietly go wrong.
Batches and expiry
In the business modes that keep batches — pharmacy, pharma distribution, supermarket, hospital and lab — batch numbers and expiry dates are recorded as stock is received, with a register of what has expired and what expires within 30, 90 and 180 days, valued at cost, and the batch to sell next for each item.
Reorder and slow-moving
Reorder levels per item against real consumption. Slow and non-moving stock is derived from the last movement date, so the report tells you what is genuinely sitting still.
Manufacturing and job work
Bills of material with wastage, what a production run needs, and production recorded at what actually went into it plus overheads. Material sent out for job work is tracked until it comes back, with the days it has been out.
What it does not do
- A sale does not yet record which batch it came from, so “sell this batch next” is advice, not something enforced at billing.
- Landed cost — spreading freight and duty over a receipt — is built in the engine but has no screen yet.
Payroll
Payroll that posts, and keeps quiet about it
Payroll is the part of an accounting system where a leak is a person’s salary. Every number here posts to the ledger like any other voucher, and none of it reaches a log line.
Structures and statutory deductions
Earnings and deduction heads per employee, effective-dated so a revision applies from its own date. PF with the ₹15,000 wage ceiling and the employer’s split, ESI and professional tax are computed from the structure. Employer contributions post as cost, not as a note.
Attendance and loss of pay
Days worked and unpaid leave recorded per month, and the run computed from them. A preview shows every employee’s figures before anything is posted.
It stops rather than guessing
If a state’s professional-tax slab has not been entered, the run stops and says so instead of deducting nothing. A statutory figure the software cannot verify is never quietly treated as zero.
One voucher per run
Posting a run writes the payroll journal through the same posting code as every other entry, into the same audit trail, with salaries, deductions and employer cost on their own ledgers.
What it does not do
- TDS on salary is entered by you each month; it is not computed for payslips.
- Employee loans, full-and-final settlement and the bank advice file are built in the engine but have no screen yet.
- Professional-tax slabs are entered for only some states. For the rest, payroll stops and asks.
- No statutory return is filed for you. The system prepares figures; submission stays with you and your consultant.
Business modes
Thirty business modes, one set of books
A chemist thinks in batches, a builder in flats and instalments, a kirana in counter sales and the khata. Choose your trade and Falcon’s menus, words and registers change to fit it — while every amount is still posted by the same engine.
A menu for your trade
Each mode adds a section of the trade’s own registers at the top of the menu — Pharmacy, Property, Shop, Jewellery — and moves general screens the trade rarely uses out of the way. They still open if you go to them.
Your words on the screens
A builder’s customers are Buyers and its invoices Demands; a chemist’s items are Medicines; a shop’s invoices are Bills; a school’s are Fee bills.
Items that carry what your trade records
A medicine carries its salt, manufacturer, schedule and MRP; an ornament its purity and weights; a grocery item its barcode, MRP and whether it is sold loose by weight.
Screens of their own where a list is not enough
Batches and expiry for a chemist, a unit board and payment-plan demands for a builder, a counter and khata for a shop, the day’s metal rate and weight billing for a jeweller, a table board for a restaurant, trip profit for a transporter.
What it does not do
- Pharmacy: a sale does not yet record its batch, so first-expiry-first-out is advice rather than enforced at billing.
- Real estate: the 1% TDS on a property of ₹50 lakh or more and interest on late instalments are not computed.
- Shops: the counter does not read weighing-scale barcodes, split one bill across two payment methods, or close a shift.
- Jewellery: finalising a bill does not post the old-gold purchase or a scheme advance as entries of their own.
- Restaurants: a table’s bill carries one line per kitchen ticket. The e-commerce mode has registers but no desk of its own.
Intelligence
The part that tells you something
The name of this product is a claim, so here is what backs it: a ledger that keeps being checked rather than periodically trusted, and reports that are computed from postings every time they are asked for.
An integrity engine over the whole ledger
26 rules: a trial balance that does not tie, control accounts that disagree with their detail, duplicate bills, negative stock, gaps in a numbering series, periods left open, an asset register or a stock ledger that does not agree with the books. Each returns the rows that failed and says why it matters — not a red light.
A tamper-evident audit trail
Every recorded event is hashed with the hash of the event before it, per business. Change one row in the database and every later hash stops matching, and verification reports where the chain breaks.
Ageing and collections
Receivables aged into bands from the bill dates, then grouped by customer into a collections view with a stage worked out from how overdue the oldest bill is. The stage is derived on every load, so it cannot be stale.
Statements, computed not cached
Trial balance, profit and loss, balance sheet, cash flow and day book, all derived from postings. 41 milliseconds for a trial balance over a year of 100,000 vouchers on PostgreSQL — fast enough that there was never a reason to store a second copy.
Underneath all of it
One posting path, one set of rules
A sales invoice, a payroll run, a stock transfer and a bank charge recorded from a statement all end up in the same function, with the same balance check and the same audit event.
Every query scoped to your business
Every read and write is limited to your organisation and company, and an id from another business is answered as not found. Row-level security in the database adds a second lock on writes and on posting today; extending it to every read is in progress.
Built for more than one company
Companies, financial years, numbering series and group consolidation, which detects trading between group companies and shows it for elimination. Group reporting is not a separate product here.
Nothing stored twice
Every total is derived from postings. There is no cached balance to go stale, no nightly rebuild, and no support ticket that begins “the report disagrees with the ledger”.
- Integrity rules
- 26Run over the whole ledger
- Capabilities
- 69Across 8 roles
- Automated tests
- 2,410Unit and integration, run with npm test
- Isolation policies
- 95In the database, binding on writes today
Try it on your own figures.
Create an account, set up a company, post a voucher, import a statement and run the integrity checks. Free while in preview; Falcon online stores your books on servers in the United States.