Reading the books.
What is connected, when each was last read, what is waiting for a named person to approve, and what a write must satisfy before this application is allowed to make one.
Nothing on this screen reaches a real accounting system. Live Tally and live Zoho authorisation are out of scope, and every cursor, status and queue entry below is read from this application’s own tables.
The ledger connections for what is configured; the sync history for what each has brought back; the posting queue for what is drafted; and the register for the companies they belong to. Every one of them is a table of this application's own, and none of it has been read from a live Tally or Zoho instance.
8 reads, 1 of which did not answer: the group register · the register.
Nothing on this screen reaches a real accounting system. Live Tally and live Zoho authorisation are out of scope, and every cursor, status and queue entry below is read from this application’s own tables.
Every other screen reports a month, and one reports an event. This reports neither: six connections and a queue belong to no company and to no month. So where a period would go it says as at the last read across the six — when what you are looking at was true, which is what a period says everywhere else.
6 connections configured: 4 healthy, 1 offline or in error, 1 stale. 7,650 rows across 16 reads, 1 refused. 3 entries awaiting approval.
The furthest behind was read 1 Aug 06:15; the most recent 1 Sept 06:22.
Every figure on this screen opens its own workings: a connection to what it is and what it has brought back, a row count to the reads that made it up, an entry to its legs and the ledger each names. The read history is held whole.
Counted from this application's own tables. 4 of 6 healthy, across zoho and tally; 16 reads, 1 refused logged; 1 of 6 may be written to, and the rest are read only.
Nothing on this screen reaches a real accounting system. Live Tally and live Zoho authorisation are out of scope, and every cursor, status and queue entry below is read from this application’s own tables.
The ledger connections and the sync history, as at the last read across the six — 1 Sept 06:22.
All accounting is performed from the Dubai head office, so every ERP installation sits on one network and there is one agent host. The three Tally companies are three company files open on that machine and share its local address; the three Zoho organisations are read over the regional API. Two shapes, never merged: Tally advances an AlterID and Zoho a timestamp, and what a cursor means is decided by the system rather than by the shape of the string.
Tally’s interface is a local XML server. It listens on the machine Tally is installed on and is never exposed to the internet — there is no inbound rule, no port forward and no static IP at the head office.
So nothing here connects to Tally. An agent runs beside it and dials outward: it reads from the local XML server, posts what it finds to this application, and asks whether anything has been approved for writing back. Every exchange is initiated from inside the network. That also means the bridge can never be more current than the last time the agent called, which is what the cursor and the last-read time are for.
A cursor is how the bridge avoids re-reading the whole ledger. Losing one means a full re-read; moving one forward without having processed what it skipped means silent data loss, so it is only ever advanced after the batch it covers has been committed here.
A posted entry carries no favourable mark and names the connection beneath its state instead. It is the one thing this application must not show: nothing was sent, and the reference the posting act stamps says so in words rather than in a voucher number nobody returned.
Ranked adverse first, then watch, then the tests that came back clean; within a class by the finding’s figure as a share of the company’s revenue for the period, largest first. A balance sheet that does not tie, or a company no rate is held for, outranks any share.
Adverse first, then watch, then clear. Within a class the rank is DAYS and not money, because nothing on this screen is money: a connection not answering outranks one merely behind, and among those behind the furthest behind comes first.
Every check here is about this application rather than about anybody’s books, which is why no row carries a share of revenue.
the state of each of the 6 configured connections
each connection's last successful read against an assumed 31-day read cycle, at 13 Oct 04:00
the 7 entries in the posting queue, for any waiting on a named approval
the 6 write-safety guarantees against what the schema and this codebase actually hold, counting a guard that holds on one path only as outstanding
every one of the 19,512 vouchers in the books, for two sides that do not agree
Six rows at most, in two columns, adverse first: what needs acting on before what needs watching, and a clear row only where a test ran and found nothing. The rest is under Data quality at the foot of the screen, so the face never grows past what a reader can act on in a glance.
Books not answering · company not named · Not an amount: a connection that is not answering, ranked above one merely behind.. company not named (Tally Prime · Sixteen Frames Live Pvt Ltd, Dubai agent host — simulated) is not answering. Nothing can be read from that set of books until the agent reaches it again, and the cursor has not moved, so nothing has been skipped — a failed read advances nothing.
Books unread for 72 days · company not named, company not named, company not named, company not named, company not named, company not named · Not an amount: ranked on days behind, which is what this screen measures. 72 days is the furthest.. company not named 72 days · company not named 72 days · company not named 41 days · company not named 41 days · company not named 41 days · company not named 41 days. The agent is taken to read each set of books once a month — this application's assumption, since no register records a read schedule — so a connection past 31 days has missed a cycle. Everything the bridge shows for them is as at that read and not as at today.
Entries wait on an approval · company not named · Not an amount: ranked on the count waiting, because what is wrong here is that nobody has decided.. 3 entries have been drafted and not yet decided. Nothing in that state has reached an accounting system and nothing will until a named person approves it here — reads may be automatic, writes never are.
Write guarantees not built · the write path · Not an amount: ranked on how many of the six are outstanding.. Dry-run diff (not built) and Closed-period guard (drafting only) and Reversal path (not built) are outstanding. The bridge is simulated so neither has cost anything yet; both must exist before this application is allowed to write to a set of books it does not own, and the panel lists all six rather than the four that are already true.
| Company | System | Cursor | Rows read | Last sync | Write | State |
|---|---|---|---|---|---|---|
| company not namedZoho Books · Arkan Distribution FZE — simulated | zoho | 2026-08-31T23:59:59+04:00modified since | 1,857 last time | 1 Sept 06:15 | enabled | healthy |
| company not namedZoho Books · Arkan Technologies FZ-LLC — simulated | zoho | 2026-08-31T23:59:59+04:00modified since | 14 last time | 1 Sept 06:12 | read only | healthy |
| company not namedZoho Books · Blushell Marine FZE — simulated | zoho | 2026-07-31T23:59:59+04:00modified since | 338 last time | 1 Aug 06:15 | read only | stale |
| company not namedTally Prime · Sixteen Frames Films Pvt Ltd, Dubai agent host — simulated | tally | 41200AlterID | 116 last time | 1 Sept 06:21 | read only | healthy |
| company not namedTally Prime · Sixteen Frames Music Pvt Ltd, Dubai agent host — simulated | tally | 18640AlterID | 10 last time | 1 Sept 06:22 | read only | healthy |
| company not namedTally Prime · Sixteen Frames Live Pvt Ltd, Dubai agent host — simulated | tally | 9310AlterID | 2 reads, 1 refused | 1 Aug 06:24 | read only | offline |
All accounting is performed from the Dubai head office, so every ERP installation sits on one network and there is one agent host. The three Tally companies are three company files open on that machine and share its local address; the three Zoho organisations are read over the regional API. Two shapes, never merged: Tally advances an AlterID and Zoho a timestamp, and what a cursor means is decided by the system rather than by the shape of the string.
A cursor is how the bridge avoids re-reading the whole ledger. Losing one means a full re-read; moving one forward without having processed what it skipped means silent data loss, so it is only ever advanced after the batch it covers has been committed here.
The ledger connections, with what each has brought back from the sync history, as at 1 Sept 06:22.
Tally’s interface is a local XML server. It listens on the machine Tally is installed on and is never exposed to the internet — there is no inbound rule, no port forward and no static IP at the head office.
So nothing here connects to Tally. An agent runs beside it and dials outward: it reads from the local XML server, posts what it finds to this application, and asks whether anything has been approved for writing back. Every exchange is initiated from inside the network. That also means the bridge can never be more current than the last time the agent called, which is what the cursor and the last-read time are for.
Nothing on this screen reaches a real accounting system. Live Tally and live Zoho authorisation are out of scope, and every cursor, status and queue entry below is read from this application’s own tables.
Nobody is signed in. This deployment is being read under its demo identity, which reads as a viewer and is not a person. An approval is a name against a write, and only the CFO or the promoter may give one — the posting queue’s own policy refuses the change to anyone else. Everything above is a read and is shown in full. Sign in as yourself to approve this.
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 posting queue, with the names on it read from profiles and the destination of an approved entry taken from the connection it names rather than re-derived.
A posted entry carries no favourable mark and names the connection beneath its state instead. It is the one thing this application must not show: nothing was sent, and the reference the posting act stamps says so in words rather than in a voucher number nobody returned.
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.
Nothing on this screen reaches a real accounting system. Live Tally and live Zoho authorisation are out of scope, and every cursor, status and queue entry below is read from this application’s own tables.
| Guarantee | What it means | State |
|---|---|---|
| Idempotency key | Minted when the draft is created, not when it is sent, so a retry after a timeout cannot post the same entry twice. | in the schema |
| Dry-run diff | The approver sees exactly what will change in the target system before approving, not a summary of it. | not built |
| Named approval | A stored approval against a named person. No write is automatic; reads may be. | in the schema |
| Closed-period guard | A closed period blocks drafting — the price-change screen refuses a change dated into a closed month. It does not block posting, and cannot: a queued entry records when it was drafted and never which month it would land in, so there is nothing to test a lock against. | drafting only |
| Reversal path | Every posting has a stated way to be reversed. Nothing is deleted; a correction is a new entry. | not built |
| Append-only audit log | The audit log takes inserts and nothing else. What happened cannot be edited afterwards. | in the schema |
The bridge is simulated, so none of these has been exercised against a real system. What is claimed here is the design the write path must satisfy before it is switched on, not a report that it has been — which is why the two that are not built say so rather than being left out.
No write to any accounting system happens without a stored, named human approval. Reads may be automatic; writes never are.
Read from the schema and from this codebase rather than from any books: what 001_schema.sql holds, and what the drafting and approving paths actually do.
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 screen that listed what a write must satisfy and dropped the two it does not yet satisfy would be claiming a guarantee. The panel exists to be used before the write path is switched on, and a list holding only what is already true cannot be used for that.
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.
Nothing on this screen reaches a real accounting system. Live Tally and live Zoho authorisation are out of scope, and every cursor, status and queue entry below is read from this application’s own tables.
The agent reads each set of books once a month, on the first of the month following. So a connection more than a read cycle behind has missed one, and the reference rule is that cycle rather than a number anybody chose. A connection reading nightly would want a different rule; this one is how the bridge was specified to be run — which is not the same as how often it has actually been read, and is deliberately not taken from it.
How often the agent runs is this application’s assumption and not a figure from any register: no connection records a read schedule. It is taken as one read a month, on the first of the month following, because that is how the bridge was specified to be run. It is deliberately not derived from how often the connections have actually been read — a threshold taken from the behaviour it judges could never detect a change in that behaviour, and a cadence that slipped to forty days would quietly become the new rule.
The connection table above states the same last-read times and states them exactly. This drawing is the one question on the screen a reader answers by scanning rather than by reading a column: which connections are behind, and by how much against each other.
Where two connections were last read in the same run they sit at the same distance, and the order then separates them from the connections that are current rather than from each other. What the drawing adds over the table is the distance, not a ranking among equals.
Each connection's last successful read from the sync history, against 13 Oct 04:00. A connection whose last attempt failed is measured from the last read that worked, because a failed attempt is not a sync.
The agent reads each set of books once a month, on the first of the month following. So a connection more than a read cycle behind has missed one, and the reference rule is that cycle rather than a number anybody chose. A connection reading nightly would want a different rule; this one is how the bridge was specified to be run — which is not the same as how often it has actually been read, and is deliberately not taken from it.
How often the agent runs is this application’s assumption and not a figure from any register: no connection records a read schedule. It is taken as one read a month, on the first of the month following, because that is how the bridge was specified to be run. It is deliberately not derived from how often the connections have actually been read — a threshold taken from the behaviour it judges could never detect a change in that behaviour, and a cadence that slipped to forty days would quietly become the new rule.
The connection table above states the same last-read times and states them exactly. This drawing is the one question on the screen a reader answers by scanning rather than by reading a column: which connections are behind, and by how much against each other.
company not named 72 days · company not named 72 days · company not named 41 days · company not named 41 days · company not named 41 days · company not named 41 days
1 action · 3 watch · 1 clear.
Adverse first, then watch, then clear. Within a class the rank is DAYS and not money, because nothing on this screen is money: a connection not answering outranks one merely behind, and among those behind the furthest behind comes first.
Every check here is about this application rather than about anybody’s books, which is why no row carries a share of revenue.
Read from this application's own tables. 8 reads were made for this screen and 7 answered; 1 did not, and the line names it. Every figure on this screen opens its own workings, down to the vouchers behind it.
the state of each of the 6 configured connections
each connection's last successful read against an assumed 31-day read cycle, at 13 Oct 04:00
the 7 entries in the posting queue, for any waiting on a named approval
the 6 write-safety guarantees against what the schema and this codebase actually hold, counting a guard that holds on one path only as outstanding
every one of the 19,512 vouchers in the books, for two sides that do not agree
Books not answering · company not named · Not an amount: a connection that is not answering, ranked above one merely behind.. company not named (Tally Prime · Sixteen Frames Live Pvt Ltd, Dubai agent host — simulated) is not answering. Nothing can be read from that set of books until the agent reaches it again, and the cursor has not moved, so nothing has been skipped — a failed read advances nothing.
Books unread for 72 days · company not named, company not named, company not named, company not named, company not named, company not named · Not an amount: ranked on days behind, which is what this screen measures. 72 days is the furthest.. company not named 72 days · company not named 72 days · company not named 41 days · company not named 41 days · company not named 41 days · company not named 41 days. The agent is taken to read each set of books once a month — this application's assumption, since no register records a read schedule — so a connection past 31 days has missed a cycle. Everything the bridge shows for them is as at that read and not as at today.
Entries wait on an approval · company not named · Not an amount: ranked on the count waiting, because what is wrong here is that nobody has decided.. 3 entries have been drafted and not yet decided. Nothing in that state has reached an accounting system and nothing will until a named person approves it here — reads may be automatic, writes never are.
Write guarantees not built · the write path · Not an amount: ranked on how many of the six are outstanding.. Dry-run diff (not built) and Closed-period guard (drafting only) and Reversal path (not built) are outstanding. The bridge is simulated so neither has cost anything yet; both must exist before this application is allowed to write to a set of books it does not own, and the panel lists all six rather than the four that are already true.