About Nexus Ledger
Built by an Amazon seller. Books that prove themselves.
Connect your Amazon account once through the official Selling Partner API — read-only, no buyer personal data. Settlements, fees, refunds and reserves become balanced double-entry IFRS journal entries; inventory is relieved at weighted-average cost on every sale; and the trial balance ties to the cent. The entry on the right assembles itself as you scroll — and lands balanced.
A real Amazon settlement assembles into a balanced double-entry journal entry — revenue, referral and FBA fees, refunds, and weighted-average cost of goods sold — with debits equal to credits at 34,160.00.
FIG 1 — Settlement → Journal entry
Amazon settlement · Mar 1–14
- IFRS double-entry
- ZATCA-aware
- KSA 15% / UAE 5% VAT
- Weighted-average COGS
- Every entry seller-approved
- Multi-currency
- 11-year audit retention
- Read-only · no buyer PII
- Profit by SKU
- Bilingual EN + AR
What we believe
Three convictions, encoded — not advertised.
These are not slogans. Each one lives in a database constraint, an RLS policy, or an agent prompt — so the product cannot drift from them on a future pull request.
Integrity
Debits equal credits, or it does not post.
Every journal entry must satisfy SUM(debits) = SUM(credits) within ±0.0001. The check runs as a database constraint trigger, not in application code — so even an AI bug or a stray service-role write is rejected at commit time.
- Immutable once posted — corrections are reversal pairs
- Period close requires the trial balance to tie
Traceability
Every field drills to its pixel.
A trial-balance row drills into its journal entries; each entry into its source settlement or supplier invoice; each extracted document into the OCR/LLM job that produced it — model, prompt version, confidence. If the chain breaks, the field is wrong.
- Source document behind every posted figure
- Append-only audit log, 11-year retention
Boundaries
Default-deny, and the AI is bound too.
The model never holds a service-role key — it reads what a bookkeeper would read, cites entry numbers, and never invents figures. If a workflow would need one seller’s data to leak into another’s view, we do not ship it; we build the safe boundary instead.
- Customer Data is never used to train any model
- Row-level isolation per seller, even within one workspace
How it works
Connect Amazon. The books assemble themselves.
One pipeline runs end to end. A settlement lands and walks itself from a read-only API pull to a closed period — each step a real part of the engine, each output traceable back to the transaction that produced it.
- STEP 01Connectread-only
Link Amazon through the official Selling Partner API
A one-time read-only connection — no buyer personal data, no write access. Finances, settlements, fees, refunds and reserves flow in as structured events, not a screenshot of a report. Supplier and Alibaba purchase orders are captured the same way, by upload or extraction.
- STEP 02Decompose
Each settlement splits into its real lines
A payout never lands as one opaque deposit. It is decomposed into revenue, referral and selling fees, FBA fulfilment fees, refunds, and reserve movements — each line mapped to an account in the IFRS-aligned chart, ready to post.
- STEP 03ComposeDR = CR
A balanced double-entry journal entry is proposed
The decomposed lines compose into one journal entry where SUM(debits) = SUM(credits) is enforced by a database constraint trigger, not application code. If it cannot balance, it does not propose — there is no half-posted state.
- STEP 04RelieveWAC
Inventory relieves at weighted-average cost on every sale
A perpetual subledger holds landed cost from supplier purchase orders in multiple currencies, with freight and duty. Every unit sold relieves inventory at its weighted-average cost, so cost of goods sold and profit-by-SKU come off real, balanced books — not a dashboard estimate.
- STEP 05Tax15% / 5%
GCC VAT is computed per line, ZATCA-aware
KSA 15% and UAE 5% VAT are computed per line from the first entry. ZATCA-aware capture reads the UUID, QR payload and hash on GCC purchase invoices and flags any missing-QR document, feeding a reconciled VAT register.
- STEP 06Approve
Nothing auto-posts — prepare → check → approve
Every entry waits for a human. Segregation-of-duties blocks self-approval on multi-user workspaces, and a 30-day cold-start window holds every new workspace to heightened review. The AI proposes; named people decide; posted entries are immutable and corrected only by reversal pairs.
- STEP 07Tie± SAR 0.01
The trial balance ties, then the period closes
A materialised trial balance refreshes as entries post; every row drills back to its journal entry, its source settlement or invoice, and the extraction job that produced it. Period close requires the trial balance to tie within ±SAR 0.01 — a closed period refuses new entries without an explicit adjustment flag and admin role.
Inside the engine
The accounting depth a connector never had.
A settlements connector hands a spreadsheet a number. Nexus runs the whole subledger: perpetual inventory, multi-currency, period close, reversal control, an append-only audit trail, and Saudi salary templating — the parts that make books an auditor will sign.
Perpetual weighted-average inventory
A real subledger, not a month-end estimate. Receipts at landed cost, relief at weighted-average cost on every sale, with shrinkage and true-up entries — tied to the GL inventory account.
Multi-currency at the right rate
Settlements in USD convert to SAR or AED at the journal entry’s posting-date FX rate from a daily feed. Realised gain or loss books to a separate account at settlement; unrealised at period-end.
Period close that must balance
Closing a period requires the trial balance to tie within ±SAR 0.01. Once closed, the period refuses new entries unless they carry an explicit adjustment flag and an admin role.
Posted is immutable
A posted journal entry can never be silently mutated. Corrections create a new reversal entry linked to the original; the reversal pair is visibly distinct in the trial balance and explorer.
Append-only audit log
Every state change writes actor, from-state, to-state, a payload diff, timestamp and IP. The log has no UPDATE or DELETE policy — it is evidence, retained 11 years to clear the ISA 230 / SOCPA bar.
Every figure drills to its source
A trial-balance row drills to its journal entries, each entry to its source settlement or supplier invoice, each document to a signed-URL page render and the OCR / LLM job — model, prompt version, confidence.
Who we serve
Two kinds of seller. One workflow engine.
The same balance-or-it-doesn’t-post engine runs underneath both — what differs is the access model.
Owner-operators running their own books.
Owner-operators based in or selling from the GCC who keep their books inside one workspace. Connect Amazon once and settlements, fees, refunds and reserves become balanced entries; supplier and Alibaba purchase orders feed weighted-average-cost inventory, so gross margin and profit-by-SKU are real, not estimated. The founder runs their own FBA business on Nexus.
- One workspace, one chart of accounts, one book of record
- Weighted-average-cost inventory from supplier purchase orders
- Profit by SKU you can actually defend
The proof is the product
Not a claim — the actual artifacts.
A trial balance whose debits tie to credits, a per-line VAT summary, and an approval queue where nothing posts itself. Real fixture numbers, balanced to the cent.
| Account | Debit | Credit |
|---|---|---|
| 1100Amazon clearing | 19,100.00 | — |
| 1330Inventory — FBA (WAC) | — | 9,360.00 |
| 4000Amazon sales — US | — | 24,800.00 |
| 5000Cost of goods sold (WAC) | 9,360.00 | — |
| 5210Referral & selling fees | 3,200.00 | — |
| 5220FBA fulfilment fees | 1,800.00 | — |
| 4001Sales returns & refunds | 700.00 | — |
| Totals | 34,160.00 | 34,160.00 |
| Type | Base | Rate | VAT |
|---|---|---|---|
| Output VAT — sales (KSA) | 24,800.00 | 15% | 3,720.00 |
| Input VAT — supplier (KSA) | 9,360.00 | 15% | 1,404.00 |
| Net VAT payable | 2,316.00 | ||
- 34,160.00JE-018839Awaiting approval
Amazon settlement · Mar 1–14
- 9,360.00JE-018838Checked
Supplier invoice · stock receipt
- 5,000.00JE-018837Posted
Referral & FBA fees
One platform vs three tools
Replace the connector, the ledger, and the spreadsheet.
The usual Amazon-seller setup stitches a settlements connector to a separate cloud ledger to an inventory spreadsheet — and the seam between them is where reconciliation breaks and the bilingual, VAT and COGS work falls through. Nexus is the one platform underneath all three.
The stitched stack
connector + ledger + spreadsheet
- A settlements connector posts a summary into a ledger it does not own — you reconcile across two systems.
- Inventory and COGS live in a spreadsheet beside the books; weighted-average cost lags the sale.
- Bilingual Arabic and GCC VAT are bolted on later, if at all — RTL print rarely survives the chain.
- A trial-balance row points at a connector summary, not the underlying settlement line.
- Three subscriptions, three data models, three places a number can drift.
Nexus Ledger, one platform
connect → auditable books
- Each settlement is decomposed and posted as one balanced entry inside the book of record itself.
- A perpetual subledger relieves weighted-average cost on every sale — profit-by-SKU on real books.
- Bilingual EN ↔ AR and KSA 15% / UAE 5% VAT are computed from the first entry, not a translation pass.
- Every trial-balance row drills to its journal entry, its source document, and the extraction job.
- One workspace, one chart of accounts, one audit trail — nothing to reconcile against itself.
The uncopyable bit
Your books speak Arabic and English.
The same journal entry — accounts, narratives, trial balance and PDF exports — stored and rendered in both languages. The one thing no settlement connector in the Amazon-seller space ships. Toggle it.
| 1100 | Amazon clearing | 19,100.00 | — |
| 5210 | Referral & selling fees | 3,200.00 | — |
| 5220 | FBA fulfilment fees | 1,800.00 | — |
| 4001 | Sales returns & refunds | 700.00 | — |
| 4000 | Amazon sales — US | — | 24,800.00 |
Same entry, both books. Flip the toggle — the ledger mirrors, right to left.
Compliance, encoded
Saudi compliance is in the schema, not a checklist.
GCC compliance is a first-class architectural concern here — encoded in the chart of accounts, the salary templates, the document capture and the retention policy from day one.
IFRS · SOCPA
Chart of accounts
A SOCPA-endorsed, IFRS-aligned default chart of accounts, customisable per client via the import wizard. Double-entry throughout; every posted entry sits in an open period and balances to the cent.
Companies Act
Bilingual books
Every account carries name_en and name_ar; journal-entry narratives are bilingual; the trial balance and ledger PDF exports render in both languages and mirror under RTL — the books an auditor reads in Arabic and an operator reads in English.
ZATCA
E-invoice inputs (Wave 23/24)
On GCC purchase invoices the product captures the ZATCA UUID, QR payload and hash, and flags any missing-QR invoice. Phase 1 consumes these inputs rather than issuing — outbound clearance is a later phase.
GOSI
Salary templating
Salary journal-entry templates auto-split social-insurance contributions per nationality — the Saudi cap base and the expat employer-only rate handled in template, not by hand.
PDPL · SDAIA
Data residency
Personal-data processing runs in an EU region with GDPR adequacy under a DPA, with an in-KSA self-hosted path documented for tenants that require data to stay in the Kingdom. Customer data is never used to train any model.
VAT
Per-line tax + register
A tax-code table drives KSA 15% and UAE 5% VAT per line, feeding a reconciled VAT register and a filing-ready extract. We prepare the register; the customer files it with the authority.
The market we build for
A GCC Amazon seller has a specific shape.
Sellers based in or selling from Saudi Arabia and the United Arab Emirates work in Arabic and English on the same page, take settlements in USD and convert to SAR or AED, owe KSA 15% or UAE 5% VAT per line, and must hold up under ZATCA, FTA, SOCPA and PDPL scrutiny. Generic connectors built for North America or Europe strip out the GCC half of the workflow and replace it with a spreadsheet.
We start from the reality that exists: settlements with fees, refunds and reserves; supplier and Alibaba purchase orders in multiple currencies with landed freight and duty; weighted-average-cost COGS relieved on every sale; VAT registers and reconciliation; bilingual narratives; period close with adjustment entries; reversal-paired corrections; audit-log-as-evidence. Then we layer AI on top — settlement-to-entry composition, supplier-invoice extraction, the AI accountant grounded in the live ledger — to compress the busy work of retyping.
The win condition is not “replace the bookkeeper.” It is: let the seller, or their bookkeeper, spend their time on the business — not retyping settlements and supplier invoices. That is the wedge.
Who built it
A seller with accounting depth, tired of three tools.
Nexus Ledger is built by an Amazon seller who runs their own FBA business on it — and who has closed bilingual books in the GCC, worked through SOCPA-aligned reporting, and reconciled settlements, fees and inventory by hand across a settlement connector, a cloud ledger and a spreadsheet. Nexus replaces those three tools with one traceable book of record. We are building the tool we wished we had, and we use it every day.
The Service is delivered under the Nexus Ledger AI (Pending Registration) brand. Company registration is in progress; the registered jurisdiction will be announced once it completes. Until then, the contracting entity for pilots is the sole-proprietor operator named in the Terms of Service.
What we do not do
Lines we hold on purpose.
Crossing any of these would dilute the wedge — so we don’t.
No auto-post
AI proposes. People decide.
During Phase 1 and the 30-day cold-start window for every new workspace, every journal entry requires human approval before it posts. The AI drafts; you approve.
No filing
We prepare; you file.
The Service prepares VAT registers, ZATCA-aware extracts, audit packs and trial balances. Filing those with ZATCA, the FTA or any authority is the customer’s responsibility.
No bundled ERP
Bookkeeping is the core, not a bundle.
HR, Procurement and CRM are real workflows but they are not part of the core accounting tier — they are opt-in, separately scoped add-ons. Sellers who only want bookkeeping pay only for bookkeeping.
Questions sellers ask
The honest answers.
A one-time, read-only connection through Amazon’s official Selling Partner API — financial events, settlements, fees, refunds and reserves. No write access and no buyer personal data. We read what a bookkeeper would read to post your books.
Want to see settlements become a real ledger?
The interactive demo is live and uses a fully anonymised reference dataset.