An entry, and what would be sent
The price protection claim receivable — Galaxy A17 5G 256GB, Kenya, 1 August 2026. A seeded 3,000 units still in the channel at a fall of 11.9700 USD a unit and an assumed coverage of 60 per cent. Seeded by 066; no price change raised it.
No write to any accounting system happens without a stored, named human approval. Reads may be automatic; writes never are.
The posting queue, with the names read from the reader register, the ledger names from this company’s account mapping, and the destination from the connection the approval named.
Every read this screen depends on answered.
Every other screen reports a month. A posting to approve is not a period, and bending one into a month would state a figure about the month that is not the figure this screen is about. So the entry and the day it was raised stand where a period would.
A queued entry records when it was drafted, approved and posted, and never which accounting month it would land in. So the closed-period guard §8 requires on posting cannot be applied to one: there is nothing to test against the months a company has closed. The drafting half is enforced where the date still exists — on the price-change screen, against the change’s own effective date — and it is lost the moment the draft is written.
No connection is opened and no request is made. The entry is marked posted, the time is stamped, and the reference written against it says in words that nothing was sent — it is not a Zoho journal id and not a Tally voucher GUID, because inventing something that looked like one is how a demonstration becomes a figure somebody quotes to an auditor.
The price protection claim receivable — Galaxy A17 5G 256GB, Kenya, 1 August 2026. A seeded 3,000 units still in the channel at a fall of 11.9700 USD a unit and an assumed coverage of 60 per cent. Seeded by 066; no price change raised it.
Approving writes that person’s name, their role and the time to the entry, and names the set of books it is destined for; what would then be sent is shown in full before anything is put through. Nothing in that state has reached an accounting system, and nothing will until a named person approves it here.
The entry itself, raised 9 Sept 12:20. Nothing here has been read from a live Tally or Zoho instance.
28 months closed for this company — context, not a guard on this act.
A queued entry records when it was drafted, approved and posted, and never which accounting month it would land in. So the closed-period guard §8 requires on posting cannot be applied to one: there is nothing to test against the months a company has closed. The drafting half is enforced where the date still exists — on the price-change screen, against the change’s own effective date — and it is lost the moment the draft is written.
No connection is opened and no request is made. The entry is marked posted, the time is stamped, and the reference written against it says in words that nothing was sent — it is not a Zoho journal id and not a Tally voucher GUID, because inventing something that looked like one is how a demonstration becomes a figure somebody quotes to an auditor.
| Group account | In this company’s books | DebitUSD | CreditUSD |
|---|---|---|---|
| Claims receivable from principal1220 | no ledger mapped | — | |
| Cost of goods sold5100 | Cost of goods sold | — | |
| Total | The entry balances |
Each leg against the group chart, and against the ledger this company's own books keep it in.
A queued entry records when it was drafted, approved and posted, and never which accounting month it would land in. So the closed-period guard §8 requires on posting cannot be applied to one: there is nothing to test against the months a company has closed. The drafting half is enforced where the date still exists — on the price-change screen, against the change’s own effective date — and it is lost the moment the draft is written.
The posting queue of Arkan Distribution FZE. The account mapping is read backwards for this: it is stored as source ledger to group account, and posting asks the same question the other way round. Where two ledgers map to one group account the answer is named rather than picked.
A group account says what the entry means to this group; the ledger name says what it will be called in the books it lands in. An approver who can see only one of them is approving a translation nobody showed them.
A queued entry records when it was drafted, approved and posted, and never which accounting month it would land in. So the closed-period guard §8 requires on posting cannot be applied to one: there is nothing to test against the months a company has closed. The drafting half is enforced where the date still exists — on the price-change screen, against the change’s own effective date — and it is lost the moment the draft is written.
No connection is opened and no request is made. The entry is marked posted, the time is stamped, and the reference written against it says in words that nothing was sent — it is not a Zoho journal id and not a Tally voucher GUID, because inventing something that looked like one is how a demonstration becomes a figure somebody quotes to an auditor.
| Act | Who | When |
|---|---|---|
| Raised | — | 9 Sept 12:20 |
| Approved | not heldthe CFO | 10 Sept 15:04 |
This entry has already been approved.
What is left is to look at what would be sent, and to post it.
The approval is recorded on the entry itself — the approver, their role and the time — and none of the three is ever overwritten. There is no separate record of who put the entry through: the queue holds a time but no name for that act, which is worth knowing before this is pointed at real books.
The approval is recorded on the entry itself — the approver, their role and the time — and none of the three is ever overwritten. There is no separate record of who put the entry through: the queue holds a time but no name for that act, which is worth knowing before this is pointed at real books.
No write to any accounting system happens without a stored, named human approval. Reads may be automatic; writes never are.
Approving writes that person’s name, their role and the time to the entry, and names the set of books it is destined for; what would then be sent is shown in full before anything is put through. Nothing in that state has reached an accounting system, and nothing will until a named person approves it here.
The entry itself, with the names read from the reader register. The approver, their role and the time are written by the approval and are never overwritten.
A rejected entry carries nobody’s name and no time. The queue keeps an approver, their role and the time they approved, and keeps nothing answering to any of the three for a rejection — so a decision not to post is anonymous where a decision to post is named. That is a gap in the register rather than in this screen, and the approver’s own place is left empty rather than borrowed: filling it would put somebody’s name against a thing they refused.
A queued entry records when it was drafted, approved and posted, and never which accounting month it would land in. So the closed-period guard §8 requires on posting cannot be applied to one: there is nothing to test against the months a company has closed. The drafting half is enforced where the date still exists — on the price-change screen, against the change’s own effective date — and it is lost the moment the draft is written.
No connection is opened and no request is made. The entry is marked posted, the time is stamped, and the reference written against it says in words that nothing was sent — it is not a Zoho journal id and not a Tally voucher GUID, because inventing something that looked like one is how a demonstration becomes a figure somebody quotes to an auditor.
You may not read the audit log. Its policy admits the promoter and the CFO, and you are reading as a viewer.
This is not an empty log. Row level security filters rather than refuses, so a reader without the role is handed nothing and told nothing — which is why this screen decides from your role and not from the number of rows it got back.
An approval is recorded on the entry itself — the approver, their role and the time — and not in the audit log. Approving writes those three columns and writes no audit row, so the entry is the record of who decided and when; the log holds what else this application did to it.
An approval is recorded on the entry itself — the approver, their role and the time — and not in the audit log. Approving writes those three columns and writes no audit row, so the entry is the record of who decided and when; the log holds what else this application did to it.
The append-only record of what this application did, as against what it holds on the entry itself.
An approval is recorded on the entry itself — the approver, their role and the time — and not in the audit log. Approving writes those three columns and writes no audit row, so the entry is the record of who decided and when; the log holds what else this application did to it.
The append-only log, scoped to this entry. Its policy admits the promoter and the CFO; row level security filters rather than refuses, so a reader without the role is handed nothing and told nothing — which is why this panel decides what it may show from your role and never from the number of rows it got back.
A read that failed, a register you may not see, and a register that holds nothing are three different statements. The middle two arrive here looking identical — nought rows and no error — and say opposite things.
An approval is recorded on the entry itself — the approver, their role and the time — and not in the audit log. Approving writes those three columns and writes no audit row, so the entry is the record of who decided and when; the log holds what else this application did to it.
No connection is opened and no request is made. The entry is marked posted, the time is stamped, and the reference written against it says in words that nothing was sent — it is not a Zoho journal id and not a Tally voucher GUID, because inventing something that looked like one is how a demonstration becomes a figure somebody quotes to an auditor.
POST https://www.zohoapis.com/books/v3/journals?organization_id=seeded-org-8841007
{
"journal_date": "2026-09-09",
"reference_number": "seed-066:price-change:DIST:SM-A176-256:KE:2026-08-01:114.2600:claim_receivable",
"notes": "The price protection claim receivable — Galaxy A17 5G 256GB, Kenya, 1 August 2026. A seeded 3,000 units still in the channel at a fall of 11.9700 USD a unit and an assumed coverage of 60 per cent. Seeded by 066; no price change raised it.",
"line_items": [
{
"account_id": null,
"debit_or_credit": "debit",
"amount": 21546.0000,
"description": "1220 Claims receivable from principal"
},
{
"account_id": "Cost of goods sold",
"debit_or_credit": "credit",
"amount": 21546.0000,
"description": "5100 Cost of goods sold"
}
]
}One leg of this entry could not name a ledger, so the account is empty above and the entry is refused.
That refusal is the honest half of the mapping: an entry that cannot name its account is an entry that cannot post, and a payload that quietly dropped the line would post half a journal.
| Field | Value | Read from |
|---|---|---|
| api_base | https://www.zohoapis.com/books/v3 | The connection to this company’s books. |
| organization_id | seeded-org-8841007 | The connection’s external identifier, which for Zoho is the organisation id. |
| journal_date | 2026-09-09 | The day the entry was raised. The queue carries no voucher date of its own, so this is the date the draft was made rather than the date the change took effect. |
| reference_number | seed-066:price-change:DIST:SM-A176-256:KE:2026-08-01:114.2600:claim_receivable | The entry’s own identity, minted when it was drafted. It is what would let a retry after a timeout be recognised in Zoho rather than written twice. |
| notes | The price protection claim receivable — Galaxy A17 5G 256GB, Kenya, 1 August 2026. A seeded 3,000 units still in the channel at a fall of 11.9700 USD a unit and an assumed coverage of 60 per cent. Seeded by 066; no price change raised it. | The narration the draft wrote. |
| line_items[].account_id | 1 of 2 named | The account mapping for this company, read backwards: group account to the ledger that company’s books use. |
| line_items[].amount | as drafted | The debit or the credit the draft stored, to four places, unrounded and unparsed. |
The request itself, before anything happens, built from the approved entry and the account mapping for this company.
Built here from the entry and the mapping, and addressed to the connection the approval named. Nothing is read from a vendor and nothing is sent to one.
Neither shape has been checked against the vendor’s published contract. The build host’s egress proxy blocks Zoho’s API documentation and Tally’s alike, so what is shown is this application’s reading of the contract it was specified to build rather than a transcription of the vendor’s own. Treat it as unverified against the vendor specification until somebody with the documentation open has read it.
An approver who is shown a summary is approving the summary. The body itself is what would go, and the table beneath it names the column every field was read from, so a figure in it can be checked rather than trusted.
Treat both shapes as this application’s reading of a contract it could not open, until somebody with the vendor documentation has read them.
No connection is opened and no request is made. The entry is marked posted, the time is stamped, and the reference written against it says in words that nothing was sent — it is not a Zoho journal id and not a Tally voucher GUID, because inventing something that looked like one is how a demonstration becomes a figure somebody quotes to an auditor.
No connection is opened and no request is made. The entry is marked posted, the time is stamped, and the reference written against it says in words that nothing was sent — it is not a Zoho journal id and not a Tally voucher GUID, because inventing something that looked like one is how a demonstration becomes a figure somebody quotes to an auditor.
The entry’s identity was minted when it was drafted and is unique across the queue, so a second attempt — a double click, a reload, a retry after a timeout — addresses the same identity, finds it spent, and changes nothing. That refusal is the database’s rather than this screen’s.
Nobody is signed in. This deployment is being read under its demo identity, which reads as a viewer and is not a person.
Sign in as yourself. The payload below is a read and is shown in full whoever is looking at it.
What the control does, and what it does not do.
No connection is opened and no request is made. The entry is marked posted, the time is stamped, and the reference written against it says in words that nothing was sent — it is not a Zoho journal id and not a Tally voucher GUID, because inventing something that looked like one is how a demonstration becomes a figure somebody quotes to an auditor.
The entry itself. Posting stamps a time and a reference, and reads nothing from any vendor because it addresses none.
No connection is opened and no request is made. The entry is marked posted, the time is stamped, and the reference written against it says in words that nothing was sent — it is not a Zoho journal id and not a Tally voucher GUID, because inventing something that looked like one is how a demonstration becomes a figure somebody quotes to an auditor.
Every read this screen depends on answered, so nothing about this entry is being taken on trust.
A queued entry records when it was drafted, approved and posted, and never which accounting month it would land in. So the closed-period guard §8 requires on posting cannot be applied to one: there is nothing to test against the months a company has closed. The drafting half is enforced where the date still exists — on the price-change screen, against the change’s own effective date — and it is lost the moment the draft is written.
| What | Value |
|---|---|
| Connection | Zoho Books · Arkan Distribution FZE — simulated |
| System | zoho |
| Address | https://www.zohoapis.com/books/v3 |
| Organisation | seeded-org-8841007 |
| Identity | seed-066:price-change:DIST:SM-A176-256:KE:2026-08-01:114.2600:claim_receivableMinted when the entry was drafted, and what refuses a second posting. |
The ledger connections of Arkan Distribution FZE. Every connection in this deployment is labelled simulated, and nothing on this screen has reached a live Tally or Zoho instance.
The ledger connections of Arkan Distribution FZE. Every connection in this deployment is labelled simulated, and nothing on this screen has reached a live Tally or Zoho instance.
Which set of books this entry is destined for, fixed at approval and never re-derived: a connection added or disabled since must not change where an approved entry says it was going.
The ledger connections of this company, and the one this entry names.
A posted row that renames its own destination is a record of nothing. The approval names the connection, and every screen after it reads that name rather than asking the question again.
No connection is opened and no request is made. The entry is marked posted, the time is stamped, and the reference written against it says in words that nothing was sent — it is not a Zoho journal id and not a Tally voucher GUID, because inventing something that looked like one is how a demonstration becomes a figure somebody quotes to an auditor.
This is the only screen in the application where a reader takes an action, so what a read could not confirm belongs in front of them before they act rather than after.
A queued entry records when it was drafted, approved and posted, and never which accounting month it would land in. So the closed-period guard §8 requires on posting cannot be applied to one: there is nothing to test against the months a company has closed. The drafting half is enforced where the date still exists — on the price-change screen, against the change’s own effective date — and it is lost the moment the draft is written.
Every read this screen depends on answered.
- the posting queue · one entry · answered
- the group register · register (posting) · answered
- the ledger connections · for this entry · answered
- the account mapping · for this entry · answered
- the group chart of accounts · posting · answered
- the reader register · approver · answered
- the reader register · the names on this entry · answered
- the audit log · what was done to this entry · answered
- the closed periods · this company · answered
A queued entry records when it was drafted, approved and posted, and never which accounting month it would land in. So the closed-period guard §8 requires on posting cannot be applied to one: there is nothing to test against the months a company has closed. The drafting half is enforced where the date still exists — on the price-change screen, against the change’s own effective date — and it is lost the moment the draft is written.
A control that hid itself where something was unconfirmed would leave the reader unable to learn why. It shows, and says what is unconfirmed, so the decision is theirs and informed rather than refused after the fact.
No connection is opened and no request is made. The entry is marked posted, the time is stamped, and the reference written against it says in words that nothing was sent — it is not a Zoho journal id and not a Tally voucher GUID, because inventing something that looked like one is how a demonstration becomes a figure somebody quotes to an auditor.