BookingHash · LedgerHash · StockHash (in development)
Accordly builds the systems of record a business runs on: a bookings engine and an accounting engine whose every fact is sealed into a SHA-256 hash chain and verified deterministically, built so that people, accounting firms and, in time, AI agents can rely on the record.
Sandboxes run on staging with test data. Production access is by waitlist.
Accordly is the parent brand of BookingHash and LedgerHash. StockHash is in development and an MCP layer for AI agents is planned; neither is available yet.
Each engine is a tenant-scoped API. Create an organisation in the Portal, open a sandbox, and your API secret is shown once.
Bookings Sandbox on staging
Availability, holds and bookings with a hash-chained history for every booking. Verify any booking's diary and get a deterministic answer.
Accounting Sandbox on staging
Journal entries sealed into a hash chain, periods closed under a Merkle root, inclusion proofs you can verify offline.
Inventory In development
A stock and inventory engine on the same record discipline. In development; not available; no date.
The same discipline runs through both engines. Nothing is a claim you have to take on trust; it is a digest you can recompute.
A hold is placed, a booking is confirmed, a journal entry is posted. The engine records the fact and, in the same database transaction, the event that describes it.
Each event or entry is serialised canonically and hashed with SHA-256 together with the hash that came before it. Same inputs, same digest, every time.
Because every digest includes the previous one, records form a chain with a fixed head (GENESIS) and a gapless sequence. The database refuses to rewrite sealed rows.
Verification walks the chain and recomputes every hash. An altered record changes its digest and breaks every later link, and the API reports exactly where.
Two illustrations of the real mechanisms. The digests are illustrative; the rules are the ones the engines enforce.
Every event is hashed with the previous hash (SHA-256). Change one, and every later link fails verification.
Optional: a daily digest per tenant can be written to storage with Object Lock in compliance mode (write-once anchoring), enabled per tenant.
Entries are sealed with the previous hash; a closed period gets a Merkle root and a period hash chained to the previous period. One altered entry changes the root and every later period hash.
Anchoring of sealed periods to write-once storage is supported.
Planned
Planned: an Accordly MCP layer that gives AI agents permission-scoped access to BookingHash and LedgerHash through the same Accordly API, with every action landing in the engines' hash-chained records. No release date is published.
bookings:readbookings:holdledger:read event_hash a91c…4e2f Planned. The MCP layer is not available and no release date is published.
Strategy
Accordly intends to acquire or partner with accounting firms, improve the operations of those firms and their clients, and give both a system of record they can verify. This is stated as strategy and intent; no acquisition or partnership is announced here.
We publish no certification, audit or uptime claims. What we publish are the rules the engines enforce.
An API key identifies the tenant. Only an HMAC-SHA256 of the secret is stored, never the secret; an unknown key receives a uniform 401.
A sandbox API secret is displayed once, at creation, and never again.
Trials provision only in staging. The production platform doors are closed; production access exists only through waitlist onboarding.
The browser never calls an engine. Every engine call is a server-side adapter call made by the Portal.
Every fact writes its event in the same transaction, sealed into a SHA-256 chain that can be verified on demand.
Sandbox on staging
Production by waitlist
No. Sandboxes run on the staging environment of each engine with test data and test keys. They may be reset at any time and carry no availability commitment.
Through the production waitlist in the Portal. Onboarding and a separate agreement follow; there is no self-serve checkout.
We have not published pricing. Production terms are agreed during onboarding.
No. Each engine keeps its own SHA-256 hash chain inside its own PostgreSQL database. Verification is a deterministic recomputation, nothing more.
Within your tenant, yes. BookingHash returns chainValid with every booking history; LedgerHash's verify endpoints re-derive every payload and report the first mismatch, and its inclusion proofs can be checked offline against the period's Merkle root.
BookingHash supports a daily write-once anchor per tenant, enabled per tenant. LedgerHash supports writing anchor records for sealed periods to write-once storage; today that is operator-triggered, not automated.
Engine data lives in AWS in the eu-west-2 (London) region. The Portal uses Clerk for authentication. See the privacy notice for the full list of processors.
StockHash is in development and the MCP layer for AI agents is planned. Neither is available and no dates are published.
Sign up in the Portal, create an organisation, open a sandbox. When you need production, join the waitlist.
Sandboxes run on staging with test data. Production access is by waitlist.