Appearance
What Gets Created in ERPNext
ERPNext is where your clients' accounting and operational documents actually live. Kraal prepares, reviews, and coordinates the work; ERPNext records it.
That split matters when you're approving something. Kraal is not writing to its own ledger and syncing later — it is creating a real ERPNext document.
Every posting becomes a specific ERPNext document
Approving work in Transaction Processor does not write to a Kraal ledger. It creates a real document in the client's ERPNext company — a Purchase Invoice, a Sales Invoice, a Payment Entry, an Expense Claim, or a Journal Entry — and that document carries the company, currency, counterparty, and links to any related documents.
The table below is the mapping. It is worth knowing before you approve something, because the document type determines what happens downstream: what appears in AR or AP, what affects inventory, and what a reconciliation will later tie out against.
What each thing becomes
| What you're recording | ERPNext document |
|---|---|
| Vendor bill for services or overhead | Purchase Invoice |
| Vendor bill for stock you ordered | Purchase Invoice linked to the Purchase Order and Purchase Receipt |
| Customer invoice for services | Sales Invoice |
| Customer order still to be fulfilled | Sales Order |
| Goods shipped | Delivery Note |
| Goods received | Purchase Receipt |
| Customer payment | Payment Entry against the Sales Invoice |
| Supplier payment | Payment Entry against the Purchase Invoice |
| Employee expense claim | Expense Claim |
| Bank or card feed row | Bank Transaction |
| Stock transfer or adjustment | Stock Entry |
| Physical count correction | Stock Reconciliation |
| Accrual, reclass, or correction | Journal Entry |
Journal Entries are a last resort
A Journal Entry moves the ledger with no invoice, bill, or payment behind it. It's the right answer sometimes — an accrual, a reclass, a correction — but it is never Kraal's default.
When Kraal proposes a Journal Entry it tells you why no other document fits. If Kraal cannot work out what a source represents at all, it asks you rather than falling back to a balanced-but-unattributable entry.
A Journal Entry that Transaction Processor prepares always requires approval, and that approval is elevated — it needs re-authentication, and no autonomy setting relaxes it. Transaction Processor reaches for a Journal Entry only when it could not identify a better document, so there is no earned-trust case for letting one through unreviewed.
That is narrower than it sounds. It applies to Journal Entries prepared here from source material. For scheduled entries, follow the current behavior and close checklist in Recurring Entries.
Order to cash, procure to pay
If your client runs full order or stock processes, Kraal keeps the chain intact rather than creating disconnected invoices:
Customer → Sales Order → Delivery Note → Sales Invoice → Payment Entry
Supplier → Purchase Order → Purchase Receipt → Purchase Invoice → Payment EntryWhether your client needs the full chain is a setting on the client. A services business invoices directly and is never asked for a Purchase Order.
For a client that does run the full chain, a bill Kraal prepares carries the links to its Purchase Order and Purchase Receipt on each line, so the bill, the order and the receipt stay connected in ERPNext rather than becoming three unrelated documents.
Matching those three against each other — quantity and price tolerances, and a view of what does not line up — is not something Kraal does for you yet. Check the match in ERPNext before approving a stock bill.
Before anything is created
Kraal resolves the master data ERPNext requires — Customer, Supplier, Item, Account, Warehouse, tax templates, cost centre — and searches for a document that already covers the same source. A free-text supplier name is never substituted for a real Supplier record, and near-duplicate masters are not created from a spelling variation.
If something can't be resolved, you're told exactly what's missing.
After it's created
Kraal reads the document back from ERPNext and records what actually happened: whether it was submitted, what its document number is, and — for documents that move the ledger — the general ledger entries it produced.
A draft is never described as posted. If ERPNext returns an unclear result, Kraal says so rather than assuming success.
Anything that changes the ledger also marks the affected reconciliations as needing a re-run, so a posting can't quietly invalidate a reconciliation that already looks complete.