Security and reliability
Not marketing promises - principles enforced in server code, not just in the interface.
The security audit the system went through in September 2026 covers what was tested, what was found, and the controls behind the result.
-
001
Full separation between businesses
Every record in the system is tied to the account that created it. No request can read or change another business's data, at the server level, not just in the interface.
-
002
Documents you cannot change
An issued fiscal document (invoice, receipt, credit note) is digitally signed the moment it's issued and stored as a permanent snapshot. There is no way - not even through support - to edit or delete an issued document.
-
003
A signature that catches any change
The signature covers the document's fiscal fields and the snapshot stored alongside it. Change one digit in an amount, a line, or the customer details and verification fails. Full detail further down this page.
-
004
Sequential, secure numbering
Document numbers are locked atomically on the server at the time of issue. An issuance that stops midway returns the number, so the sequence stays whole and every number stays available.
-
005
Anyone who receives a document can verify it
Every issued document carries a QR code and a link to a public verification page. The customer, the accountant, or anyone holding the file can check for themselves that it is genuine and unchanged, with no account and no login. The page returns only what verification needs: whether the signature holds, the document number, the business name, the signing time and the amount.
-
006
No passwords
Login is a one-time code sent to your email. There is no password column in the system, not even a hashed one, so there is no password store to steal, brute-force, or match against a leak from another service.
-
007
Short sessions and immediate revocation
A session ends when the browser closes and expires on its own shortly after, so returning to the app means proving mailbox control again. There is also a mechanism that cuts off every open session of an account at once, triggered automatically when an account is closed and on any sensitive change to its permissions.
-
008
Secrets encrypted at rest
Sensitive connection details (like the Tax Authority connection) are encrypted with AES-256-GCM in the database, and never stored or shown in plain text on any admin screen.
-
009
Browser protections
The app loads under a policy that restricts which resources the browser may run and where it may connect, alongside headers that prevent the system being embedded in another site, file-type guessing, and address leakage. Camera, microphone and payment are disabled at the browser level, and PDF generation runs in an isolated environment with no code execution.
-
010
Rate limits
Sensitive endpoints, login first among them, are rate-limited per email address and per request source. The limit is keyed on a source identifier the caller cannot choose, so high-volume guessing is blocked rather than routed around.
-
011
Input control
Every stored field passes an explicit allowlist and shared length limits enforced on both the server and the interface, so there is no way to push a field into a record that was never meant to be written. Files and imports are checked before processing and capped in size, compressed files that try to expand in memory included.
-
012
A full activity log
Every meaningful action is written to a server-side log: issuing, cancelling, requesting an allocation number, importing, and every verification check someone runs against your document. A document's log is visible in the app, so you can see what happened to it and when.
-
013
AI that suggests, never writes
Every AI feature - receipt recognition, the "ask your books" assistant, document drafting - produces a suggestion only. No AI code writes directly to a document, expense, or customer message without explicit human approval.
-
014
Your data leaves with you
You can export the full record set as a Tax Authority Open Format file, the same format an audit asks for. No vendor lock-in: leaving Slate does not leave your books trapped in it.
-
015
Retention as the law requires
Fiscal documents are kept for 7 years as Israeli law requires, even if the account is closed - not as internal policy, but as a mechanism that cannot be bypassed.
The digital signature, in detail
What the law asks for
Section 36B of the Israeli Income Tax Regulations (Bookkeeping), 1973, defines a "computerized document" as one created, sent, received, viewed and stored by computerized means, and signed with an approved or a secure electronic signature belonging to the party issuing it. That is the condition that lets a business send an invoice as a file instead of printing and handing over paper.
The Electronic Signature Law, 2001, defines what makes a signature secure: it is unique to the holder of the signing means, created by a means under their control, and it makes any change to the document after signing detectable. That last part is the whole point. An electronic signature is not a scanned image of a handwritten one, and it is not a "signed by" line at the bottom of a PDF. It is a mechanism that gives away edits.
One condition is easy to miss: computerized documents may be sent only to a recipient who agreed in advance, in writing or electronically, before the first computerized document reaches them.
What happens the moment you issue a document
On issue, the server assembles a canonical payload from the fields that determine what the document says: id, number, type, creation time, the customer, the line items, amount, discounts, VAT, rounding, a linked document (the invoice a credit note refers to, for example) and the exchange rate on a foreign-currency document. Signed along with them is the frozen snapshot: business name, tax ID, address, logo, the customer details and the VAT rate in force at that moment.
A SHA-256 digest is computed over that payload and signed with an Ed25519 private key held on the server and never sent anywhere. The signature and the signing time are stored on the document. Every verification recomputes the digest from what is currently in the database and compares it against the stored signature, so a check catches an edit made directly in the database too.
What the signature covers, and what it deliberately does not
Operational fields that do not change what the document says, such as an internal note or a sorting tag, stay outside the signed payload. That is on purpose: editing an internal note two years later should not look like forgery. Everything that affects what the customer sees and what lands in the books is inside.
Verification without an account
Every issued document gets a public verification page, with a QR code printed on the file. Scanning it returns one of two answers: the signature holds and the document matches what was signed, or the document changed after signing. The page is rate-limited and does not expose the document contents, only what verification itself needs. The document samples include a signed file of every type, with its signature card and the link to its verification page.
What this is not
To be precise: the signing key is held and used by Slate, not on a personal smart card of yours carrying a certificate from a certification authority. The mechanism is built for the property the law asks about, reliable detection of any change made after signing, and it is not an approved electronic signature in the sense of a personal certificate issued by a certification authority. If your accountant requires a personally approved signature, that is a different product, and it is worth telling us before you start issuing.