Scope & accounting assumptions

This is a demonstration application built around the SC Technology group of nine companies, with dummy customers, suppliers and transactions. No real company data or live payment rails are used.

Base currency

The company's base (reporting) currency is GBP. Every invoice, payment and journal carries its own transaction currency (GBP, EUR or USD) plus the exchange rate used to translate it into GBP. All ledger entries are posted in GBP so the books speak one currency; original-currency amounts and rates are kept alongside each entry for reference.

Exchange rates

Rates come from the European Central Bank's daily reference rates (data.ecb.europa.eu). The ECB quotes everything against the euro, so GBP rates are derived: 1 EUR = the GBP/EUR rate, and 1 USD = (GBP/EUR) ÷ (USD/EUR). The server fetches new rates on start-up and every 6 hours. The ECB publishes on working days around 16:00 CET; for weekends and holidays the last published rate is used. The rate is filled in automatically on invoices, payments and journals but can always be overwritten with the rate actually achieved.

Chart of accounts & reporting

Every ledger account is mapped to a reporting category (Setup tab), which decides where it appears in the financial statements: fixed assets, trade receivables, other current assets, cash & bank, equity, trade payables and other current liabilities on the balance sheet; revenue, cost of sales, overheads, financial income and financial expenses on the P&L. P&L accounts are not closed off to retained earnings at year end; instead the cumulative result is shown as its own line within equity. The cash flow statement uses the indirect method.

Invoices

Sales and purchase invoices can have any number of lines, each booked to its own ledger account with its own VAT rate. Purchase invoices post Dr expense/asset lines, Dr VAT recoverable, Cr accounts payable; sales invoices post Dr accounts receivable, Cr revenue lines, Cr VAT payable.

Foreign-exchange gain/loss

A foreign-currency invoice is booked to accounts payable/receivable at the rate on the invoice date. When it is settled, from any bank account, the part settled is cleared at that original booked rate, while the bank leg is recorded at what actually went through the bank in GBP (the bank amount times the ECB rate for a foreign-currency account, or simply the GBP amount for the GBP account). The difference is posted to Realised FX gain (financial income) or Realised FX loss (financial expenses). Example: a 1,000 USD invoice booked at 800 GBP and paid from the GBP account for 750 GBP gives a 50 GBP gain.

Period-end revaluation of unrealised FX on open invoices and foreign-currency bank balances is not done yet.

Manual journals & bank statements

Manual journals can post to any account and must balance before they are saved. Bank statements are imported from CAMT files and linked to a bank ledger account (automatically via the IBAN once known). Each line is booked against an opposing account or matched to an open invoice. Note that a manual journal or bank line posted directly to accounts receivable/payable does not mark any invoice as paid; use the invoice option for that.

Users & access

Everyone logs in. An admin can do everything, including managing users (Setup → Users); a viewer can see all screens and reports but can't create, edit, pay, upload, close or delete anything - the server refuses those requests, not just the screen. Passwords are stored as scrypt hashes, an account is locked for 15 minutes after 5 wrong passwords, and a login lasts 7 days. Edits to journals record who made them.

Entities

The books hold the nine legal entities of the SC Technology group (X1-X9): three holding companies, each with its subsidiaries (X7 owns X8 and X9, X5 owns X6, X1 owns 80% of X2), and two independent UK companies (X3 and X4). Every journal, invoice, fixed asset and bank statement belongs to exactly one of them. They share the chart of accounts, cost centres, customers, suppliers and periods, but bank accounts and some other accounts belong to one entity and can only be posted to by that entity. The selector in the top bar shows one entity or all of them. Group companies are customers and suppliers of each other (marked Group): their invoices, loans and balances are tagged intercompany, reconciled on the Intercompany page and eliminated in the consolidated Financials. The existing invoices and journals are demonstration data and not meant to be accurate for these companies. All books are kept in GBP whatever each company's main currency.

Editing postings

Posted journals can be changed as long as their period is open. Manual and opening journals can be changed completely (date, reference, description, lines and amounts) and must still balance. Journals created by an invoice, payment, bank line, asset purchase or the depreciation run follow that document: their amounts and dates can't change, but the description can, and P&L lines can be moved to another P&L account and/or cost centre (a reclassification); an invoice line moves along with its ledger line. Every change is kept in the journal's history with a before and after copy.

Cost centres

Cost centres (departments) can be chosen on P&L lines only: invoice lines, manual journal lines, bank postings to a P&L account, and depreciation (taken from the asset). Balance sheet lines never carry one. Automatic FX gains/losses have no cost centre and show as "Unallocated". The Financials tab can show the P&L for one cost centre, and has a P&L per cost centre.

Periods

Every journal belongs to the monthly period of its date. Periods are created automatically when needed. Closing a period first books its depreciation and then blocks all postings dated in it; periods are closed in order and reopened in reverse order. The opening-balance journal is always treated as brought forward in the reports, never as a movement.

Fixed assets & depreciation

Assets are either machinery or inventory (fixtures, fittings & office/IT equipment - Dutch "inventaris", not stock). Each type has its own investment ledger and accumulated depreciation ledger (balance sheet) and depreciation ledger (P&L). Depreciation is straight-line: cost × yearly % ÷ 12 per month (20% = five years), from the month of acquisition until the book value is zero, with no residual value. It is posted as one journal per month, dated the last day, with each asset's cost centre on the expense line. The server checks every 6 hours and books any month that has ended; it can also be run by hand. Assets owned before the books started carry the depreciation already written off as "opening depreciation". Disposals are not modelled yet.

Paying suppliers

The Pay button opens a simulated bank payment window: choose the account to pay from and your bank, "log in" and approve. No real bank is contacted and no money moves; approving books the payment on the invoice as if the bank executed it today. When paying from an account in another currency, the bank converts at today's ECB rate and the difference with the invoice's booked rate is a realised FX gain or loss. Real payments would need an FCA-authorised Open Banking payment initiation provider (e.g. TrueLayer or Yapily), which can later replace the simulated bank behind the same button. A payment made this way would also appear on the next real bank statement; that statement line is then already settled and should be posted against accounts payable or left out.

Invoice recognition

For each supplier you can also mark where a field is: with the PDF shown next to the form, click a field (invoice number, dates, description, net amount or total) and drag a box around its value on the PDF. The app reads the text in the box and fills the field; when the invoice is saved, the position is stored for that supplier and next time that spot is read first, before any label rules. Positions are kept as fractions of the page, so they work whatever size the PDF is shown at, but they assume that supplier's layout stays the same.

Supplier invoices can be uploaded as PDF (Purchase invoices → Upload invoice PDF, or drop the file on the page). The browser reads the PDF's text with pdf.js; the server then recognises the supplier (by VAT number, IBAN, bank account, name or learned letterhead), invoice number, invoice and due date, currency, net, VAT and total, and suggests a VAT code from the rate. It uses built-in labels in English, German, French and Dutch. When the invoice is saved, the app compares what was saved with what it suggested and learns per supplier: the labels that supplier uses, its date format, its currency, its letterhead and how its invoices are booked. The PDF is kept with the invoice. Scanned PDFs without a text layer can't be read (that would need OCR or an AI service). Amounts per invoice line aren't split out yet: the net amount goes on one line.

Reimbursements

Expenses someone paid personally are claimed on the Reimbursements page, which also works on a phone: Scan receipt opens the camera. The photo is read in the browser (text recognition with Tesseract, loaded the first time it is used; PDF receipts are read with pdf.js) and the app suggests the merchant, date, currency, total, VAT and VAT code. Per merchant it learns the expense account, cost centre, VAT code and description used last time. The photo is shrunk to at most 1600 pixels and stored with the claim. Approve & book posts the claim on the receipt date: expense (net, with cost centre) and input VAT on the VAT code's account, against Employee expenses payable (2400). Pay posts Employee expenses payable against a GBP bank account. Foreign-currency receipts are translated at the rate on the claim and reimbursed in GBP at that amount. Deleting a claim's journal (Journals) sets the claim back one step.

Email inbox

Supplier invoices e-mailed to the invoice mailbox are picked up automatically: the app reads the Gmail inbox (IMAP, with a Google app password - never the normal password) and puts every PDF attachment in the Email inbox on the Purchase invoices page, where Process runs the same recognition as an upload. The mailbox is checked when an admin opens Purchase invoices (at most every 2 minutes), with Check mailbox now, and every morning at 06:00 UTC. Emails are only read, never moved, deleted or marked as read; the app remembers which emails it has imported, so each PDF comes in once. Attachments over 3 MB, and files that aren't real PDFs, are skipped.

VAT codes

Every invoice line carries a VAT code (VAT20 = 20%, VAT0 = 0%; more can be added in Setup). Each code books its VAT to its own GL accounts: input VAT on purchases (1210 for VAT20, 1220 for VAT0) and output VAT on sales (2210 / 2220). The general VAT accounts 1200 and 2200 remain for VAT that isn't from an invoice, such as payments to or refunds from HMRC. VAT booked by invoices before VAT codes existed was moved to the VAT20 accounts.

VAT

Input VAT is posted to VAT recoverable and output VAT to VAT payable. No partial exemption or reverse-charge mechanics are modelled; overseas invoices in the demo data use 0% VAT.

The VAT tab works out the nine-box VAT return per entity on the accrual basis: box 1 is the output VAT and box 4 the input VAT on the invoices dated in the period, boxes 6 and 7 their net values in whole pounds, all in GBP at the invoices' booked rates. Boxes 2, 8 and 9 (EU goods) only apply in Northern Ireland and are 0. VAT booked on the VAT ledgers by manual journals is not included; the tab shows any such difference. Filing stores the figures and produces the request body for HMRC's Making Tax Digital API. Sending it to HMRC directly needs the app to be registered as MTD software with HMRC (Government Gateway sign-in and fraud prevention headers), which this demo is not.

Persistence

The online version stores everything in a Postgres database (Neon, London), so data is kept and every visitor sees the same books. When run locally the app uses a SQLite file instead; the same queries work on both. Tables and demo data are created automatically the first time the app starts on an empty database.