Centa’s accounting methodology
Every transaction in Centa goes through one pipeline: import, duplicate check, classification, a decision (post automatically or ask a person), a journal entry on the NAS chart of accounts and matching to a document. Below is how that works in specific workflows.
- Author
- Centa AI editorial team · Centa AI product and content teamWrites the guides and product pages. Rates and deadlines are checked against the Tax Code text stored from LexUZ; feature statuses come from one list in the product code.
- Last updated
Document-to-payment workflow
Traditionally: bank statement → manual classification → manual document matching → accountant review. In Centa:
- Import. Transactions arrive from a statement (Excel/CSV), a bank API or a 1C file; documents from a PDF, a photo or Didox.
- Duplicate check. A transaction is compared by date, amount, direction and counterparty; a document by its Didox id or by type, number, date and amount. A repeat is never written twice.
- Classification. Centa assigns a category and a confidence; the company’s own rules, learned from earlier decisions, take priority.
- Decision. A confident, immaterial transaction is posted automatically; an uncertain or material one goes to the Attention queue.
- Journal entry. The entry is created on the NAS chart of accounts (for example, money received to the settlement account — Dr 5110).
- Matching. The payment is linked to an invoice or act by amount, the counterparty’s STIR, dates and number; the open balance is recalculated.
Common causes of accounting exceptions
An exception is a question that needs a person’s answer. Typical causes:
- A payment has no document.
- The document and payment amounts differ — even by 500 UZS.
- A duplicate: the same fiscal sign on two receipts, or the same document twice.
- An unclear category (for example, whether a meal is entertainment).
- A card payment without a receipt.
- A cash discrepancy at end-of-day closing.
- File rows that could not be recognised.
The decision is written to the audit trail and, if it is a rule (for example, “this counterparty is rent”), applied to later transactions. More: Exception Engine.
Corporate-card receipt workflow
- The bank shows a card payment — Centa waits for a receipt.
- An employee photographs the fiscal QR code or uploads the receipt PDF.
- The QR gives the terminal, receipt number, date and fiscal sign (not the amount).
- The receipt is matched to the payment within ±3 days; for PDF and fiscal receipts the amount must match exactly.
- No receipt — a question in Attention; two receipts with one fiscal sign — a duplicate.
Cash reconciliation workflow
Cash is kept apart from the bank, on account 5010. Cash in, cash out and cash deposited to the bank are separate transactions. At end-of-day closing the counted amount is compared with the book balance; a discrepancy goes to Attention and is closed with a reviewed adjustment. More: cash (kassa).
Partial payment workflow
Installments get a payment schedule with in-app reminders. More: partial payments.
Receipts without bank data
If a month has only receipts and no statement, Centa books them as unconfirmed payments through account 5710 — they count in expenses but not in cash. When that month’s statement arrives, the provisional entries are removed and the bank transactions are matched to the receipts in the normal way, so one payment is never counted twice.
Tax deadline workflow
The tax calendar is built from Tax Code rules; each rule is checked against the stored LexUZ text. A deadline that falls on a day off is moved. If it is unknown whether a rule applies to the company (for example, its tax regime), the deadline is marked “needs confirmation”. How tax estimates work is described in the tax methodology.
What Centa never does
- It never invents a field that is not in the document.
- It never silently overwrites the books with data from an external system.
- It never closes a discrepancy without a person’s decision.
- It never computes amounts with a language model.