About
AI bookkeeping for Amazon sellers, GCC-first.
Connect your Amazon account once through the official Selling Partner API — read-only, no buyer personal data. Nexus Ledger turns settlements, referral and FBA fees, refunds, and reserves into balanced double-entry IFRS journal entries, relieves inventory at weighted-average cost on every sale, and produces a defensible trial balance — without sacrificing the controls that real auditors and regulators expect.
Who we serve
Two kinds of seller. Same workflow engine. Different access models.
Amazon FBA sellers
Owner-operators based in or selling from the GCC who run their books inside one workspace. Connect Amazon once and settlements, fees, refunds, and reserves become balanced journal 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.
Growing sellers and their bookkeepers
Multi-marketplace sellers (US, CA, MX, with .sa and .ae) and the bookkeepers who keep their books. One workspace per seller, each with its own chart of accounts, periods, approval roles, and audit log. RLS keeps every seller's books separate even from inside the same workspace. Same workflow. Same controls.
What we believe
The choices that shape every line of the product.
Books reconcile, or the system 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. Even an AI bug or a misbehaving service-role write is rejected at COMMIT time.
Posted is immutable.
Once a JE is posted, accounts and amounts never change. Corrections happen via reversal entries linked to the original, never silent edits. UI badges, audit log, and trial balance all show the pair.
Every field is traceable.
A trial-balance row drills into its journal entries; each JE drills into its source — the settlement transaction or the supplier invoice — and each extracted document drills into the OCR/LLM job that produced it (model, prompt version, confidence). If the chain breaks, the field is wrong.
The AI is bound by the same rules as a person.
We do not give the model a service-role key. The AI accountant chat and voice read what a bookkeeper would read inside the workspace, cite JE numbers, and never invent figures. Customer Data is never used to train models — that prohibition is in our agreements with every AI subprocessor.
Compliance is encoded, not advertised.
SOCPA-aligned IFRS COA, KSA 15% and UAE 5% VAT per line, ZATCA-aware capture on GCC purchase invoices, PDPL-aware regional hosting — these live in the schema and the prompts, not in marketing claims. We describe how we are designed and aligned; certification statements are added only when independent audits land.
Default-deny, every time.
If a feature would require leaking one seller's data into another's view to make a workflow simpler, we do not ship it. We build the SECURITY DEFINER function that crosses the boundary safely instead.
The market we are building for
A GCC Amazon seller has a specific shape — bilingual, multi-currency, VAT-bound, settlement-and-inventory heavy. We optimise for that shape, not for a generic US-built settlement connector translated.
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. Amazon 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-JE composition, supplier-invoice extraction, the AI accountant chat and voice grounded in the live ledger — to compress the busy work of retyping settlements and invoices.
The win condition is not "replace the bookkeeper". The win condition 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
An Amazon seller with accounting depth who got tired of retyping settlements into a separate ledger and an inventory spreadsheet.
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
Boundaries we hold deliberately, because crossing them dilutes the wedge.
We do not auto-post.
During Phase 1 and during the 30-day cold-start window for every new workspace, every journal entry requires human approval before it posts. AI proposes; people decide.
We do not file your returns.
The Service prepares VAT registers, ZATCA-aware extracts, audit packs, and trial balances. Filing those returns with ZATCA, the FTA, or any other authority is the customer's responsibility.
We do not bundle ERP into accounting.
HR, Procurement, and CRM are real workflows but they are NOT part of the core accounting tier. They are opt-in add-ons, separately scoped and separately priced, with their own database schemas and RBAC. Sellers who only want bookkeeping pay only for bookkeeping.
We do not use Customer Data to train models.
Not for our own models, not for our subprocessors' models. This is a contractual prohibition on every AI provider in our subprocessor list, and it is a precondition to processing.
Want to see settlements become a real ledger?
The interactive demo is live and uses a fully anonymised reference dataset.