Privacy Policy — Ledgerline

Vantrel Consulting LLC · Last updated: 22 September 2026

This policy describes what Ledgerline accesses, why, who else sees it, and what we do with it. Every claim in it was written against the code that implements it and can be checked against that code.

Who we are

Ledgerline is operated by Vantrel Consulting LLC, a Florida limited liability company. We install and run software agents inside a business's existing systems — accounting, email — so the business gets the benefit without doing the integration work.

We are the data processor for the business records our clients connect. The client remains the controller of their own accounting and mailbox data. Where a client's own customers or vendors appear in that data, we process it only to provide the service the client asked for, on that client's instructions. The terms governing that relationship are in our Data Processing Addendum.

Questions, requests, or complaints: support@vantrelco.com

What we access, and why

We only ever connect systems a client explicitly authorises, through that provider's own consent screen.

A client can end either connection at any time, in two ways that both work without our involvement. From Disconnect inside the service: we ask the provider to cancel our access, then delete the stored credentials — and if the provider cannot be reached to confirm the cancellation we say so plainly rather than reporting it as done. Or from the provider's own settings, which stops our access at their end immediately. Reconnecting afterwards means granting permission again, which we set up.

Accounting system (QuickBooks Online) — read, and write only as approved. We read bills, vendors, vendor credits, purchase orders, bill payments, purchases (card, check and cash spending) and the receipts attached to them, invoices, customers, customer payments, credit memos, products and services, journal entries, accounts, the company's preferences, and financial reports. They are used to check supplier invoices against the client's own records, to show who owes the client money, to forecast cash, to review spending, to find what needs cleaning up in the books, to work through the month-end close, to keep track of the client's filing deadlines, to help the client plan, and to write the client a weekly summary, and to explain what changed in a closed month and how much of it recurs.

We write to a client's accounting system only in a small number of named ways, and only when two things are both true: writing has been switched on for that client, and a person at the client approved that specific change after seeing exactly what it would be — except for a vendor's own reply to a request the client approved, described below the list. Writing is off for every client until we switch it on at the client's request, which the Order Form records; the client can switch it off again themselves at any time. The changes that exist are:

• entering a bill or vendor credit from an invoice or credit note that arrived by email, with the document attached to it;
• recording an accrual or prepaid-expense journal entry;
• creating a customer invoice, and — only where the client chose it — asking QuickBooks to email that invoice to the customer;
• moving one uncategorised purchase line to an expense category;
• creating a vendor, from an invoice sent by a supplier the client's records do not have;
• updating a vendor's email, phone, remittance address or the client's account number with them, from that vendor's own reply to a request the client approved.

Vendor details from the vendor. Where a client approves asking a vendor to confirm their details, we email that vendor at the address in the client's records and write their reply into the client's accounting system without asking again. We write it only if Microsoft's own record shows it came from the address the request went to, carries that request's reference, and arrived after it was sent. Only the vendor's email, phone, remittance address and the client's account number with them can change, and we record each change with its previous value. We never ask for, store or write bank details. The client can switch this off in their settings.

Questions to a vendor about their own bills. Where a client approves it, we email a vendor about something their records and the client's do not agree on — an amount, a document we have no copy of, a charge above its purchase order, a possible duplicate, or something the client shows outstanding. It goes to the address in the client's records and never one taken off a document. What that message contains is the vendor's own document references and amounts, the client's own figures for the same items, and the client's name; nothing about any other vendor, and no bank details, which we never ask for. It can also carry up to two documents that the same vendor sent the client — the statement being queried and the client's copy of the invoice it concerns — which we retrieve from the client's mailbox when the message is sent and do not keep. No other document can be attached, and each one is named on the approval card before anything goes. The reply is written to nothing: it arrives in the client's mailbox, which we read for invoices, and a person there decides what it means. The client can switch this off in their settings, separately from requests to confirm a vendor's details.

We never delete or void anything, never record or make a payment, never change anyone's bank details, and never change a vendor's details except from that vendor's own reply as described above. Before a change is made it is checked again against the records as they are at that moment, and afterwards it is read back to confirm it is what was approved.

Mailbox (Microsoft 365) — read, and send only to the client's own customers and vendors. Messages and attachments in the mailbox a client nominates for supplier invoices. Used to find invoices that arrive by email and read what they say. For this we hold the Mail.Read permission.

Where a client uses the service to remind its own customers about invoices or send them statements, we also hold the Mail.Send permission, and use it to send from the client's own mailbox. Each email is one plain-text message to the single address QuickBooks holds for that customer, written from the client's own wording — or, where the client has set a test address, to that address instead of the customer's, which is how a client watches the service before anything reaches their customers. Routine reminders — before an invoice is due, and the first and second once it is overdue — are sent on the client's own timetable without waiting for approval, unless the client switches that off in their settings. A final notice, a statement, a reminder for an invoice that was already overdue when automatic reminders began, and any email the agent has added words to, always need a person.

The same Mail.Send permission is also used, when the client switches it on, to tell the client's own people that decisions are waiting for them in Ledgerline. Those messages go from a mailbox of the client's own — the one they connected, or a second one of theirs they nominate for this, which they add to the same scope — to the addresses their own users sign in with, and nowhere else. They are shown as coming from "Ledgerline", so the reader knows which system is asking for them. They say how many decisions are waiting and how long the oldest has waited, and nothing more — no amounts, no vendor or customer names, and nothing about what any decision concerns, because an inbox is forwarded and read in places the service cannot see. No more than one such message is sent in any period the client chooses, which is a day unless they change it. This is off until a client turns it on, and can be turned off again at any time in their settings.

The same permission and the same mailbox are used to email a link for setting a new password, to the address the person asking signs in with and nowhere else. That message carries no figures and nothing about the client's books. The link can be used once, stops working an hour after it is sent, and does not switch off two-step sign-in — so being able to read the mailbox is not enough to sign in. We answer the person asking in the same words whether or not that address has an account here, because the alternative is an open way to find out who does. This is on unless a client turns it off in their settings; with it off, a password is set by us on the server instead.

We cannot reply to, forward, move or delete mail, attach files, or copy anyone. Where a client scopes the permissions to a single mailbox — which we recommend and configure — we cannot read or send from any other.

Where a client approves asking a vendor to confirm their details, we use the same permission to send that vendor one plain-text message, in fixed wording, to the address in the client's records — or to the client's test address, if one is set. We read the vendor's reply from the same mailbox.

Accounts. For people who sign in: email address, display name, and a password stored only as a scrypt hash. We never store a password. Sessions are stored as a SHA-256 hash of the session token, so a copy of our database does not let anyone sign in.

What the service produces. Invoices read out of email, the questions the agents raised, the decisions a client made in response, and a plain-language history of what the agents did. Also: every change proposed to the client's books and what became of it; every email sent to a client's customer, kept whole (recipient, subject and exact text), so the client can see what was said on their behalf; cash forecasts; the weekly summaries, with the figures they were written from; the regular payments and limits a client sets; holds a client places on a bill or invoice; which bookkeeping findings a client marked as fine, by whom; and each month-end checklist item a person marked done, and each month signed off or reopened, with who did it and the month's figures as they stood; the filing deadlines a client sets, and which were marked done, by whom; the budgets a client adopts, with who adopted them; each month's analysis, with the figures it was written from; what a person typed in reply to a question; what an agent said at the end of a review; and each change made to a vendor's details from their reply, with what it was before and which request it answered.

What we do not collect

• Payment card numbers, bank account numbers or payment credentials. We hold no means of moving money and never ask for one.
• Anything from systems a client has not connected.
• Personal data about anyone for advertising, profiling or resale. We do not sell or share personal data, and we do not use it for targeted advertising.

We also do not use client data to train models, and we do not use one client's data to improve the service for another.

Who else processes it

Providing this service means data reaching a small number of others. We use no others without updating this list and telling our clients first.

Content a client's supplier writes — an invoice, an email body — is sent to Anthropic as part of processing it, and so are the names and amounts in the client's own records that the agents review. Clients should know that before connecting their systems.

A customer who receives a reminder sees it come from the client's own mailbox, in the client's own wording. We do not contact a client's customers or vendors in our own name.

Each of these is bound by its own agreement with us to process data only to provide its service. Where a client needs the specifics of one of those agreements, we will provide what we are permitted to share.

Where it is held, and how it is protected

Our servers are in New York, in the United States. Nightly backups are kept on that server, and a copy is sent to storage held by Backblaze, also in the United States, so that losing the server does not mean losing the records. We do not transfer client data outside the United States, and the processors above are engaged on their United States infrastructure.

The copy that leaves our server is encrypted before it goes, with a key whose secret half is not held on that server. Backblaze cannot read it, anyone who obtained the stored files could not read it, and neither could our own server: it can add to the archive and cannot read it back.

• Credentials for connected systems are encrypted at rest using AES-128 in CBC mode with HMAC-SHA256 authentication, with the key held separately from the database and supporting rotation. Losing that key makes stored connections unreadable rather than exposed. The system refuses to store a credential at all if no key is configured, rather than falling back to storing it in the clear.
• Each client's credentials are stored separately. One client's connection cannot be used to reach another's data.
• Access is scoped by account. A client's users see their own organisation and nothing else — enforced by the server on every request, not by the interface hiding things. This is verified by an automated test that was confirmed to fail when the scoping is removed.
• Passwords are hashed with scrypt and sessions are stored only as a SHA-256 hash of the session token. Sign-in attempts are rate-limited.
• Traffic is served over TLS. Session cookies are HttpOnly, SameSite=Lax and marked Secure, and are not readable by scripts.
• Credentials are never written to logs. Anything credential-shaped is replaced with its length before any diagnostic output.

• Documents from outside are parsed in an isolated process with a time limit, because a supplier's PDF is a file written by a stranger.

• Changes to a client's books go through one narrow path. The code that writes to an accounting system can do exactly the changes listed above and nothing else; an automated test enumerates what it can do and fails if anything is added. The code that reads cannot write at all. Sending email is likewise confined to one component that sends a single plain-text message to one address, pinned the same way.

We are a small operation and say so plainly: there is no 24-hour security team. What there is, is a narrow attack surface by design — no capability to move money, changes to a client's books only in the few named ways above and only as a person approves, and email only to a client's own customers.

How long we keep it

Decisions and history are kept for the life of the account, and are not deleted on request while the account is open. They record who approved what, when, and what they were shown at the time. A record of decisions about money that can be edited afterwards is not a record. If this conflicts with a client's own retention obligations, we will discuss it before they sign up.

The record of emails sent to a client's customers is kept for the life of the account on the same basis: it is what the client can point to when asked what was said.

Invoices read from email, forecasts, weekly summaries, and the connected-system data we cache to answer a question, are kept while the account is open.

On account closure, we delete client data within 30 days, except where we are required by law to keep it. Credentials are deleted immediately. Backups containing deleted data age out on the ordinary backup cycle — 30 days for copies on our server, 90 days for the encrypted copy held offsite — and are not restored to reinstate deleted records.

Rights

Depending on where a client or the people in their records are, they may have rights to access, correct, export or delete personal data, to opt out of sale or sharing — which we do not do — and to object to processing. Requests to support@vantrelco.com; we respond within 30 days. We do not charge for this and we will not treat anyone differently for asking.

Because we are a processor for our clients, a request from their customer or vendor should normally go to the client, and we will support them in answering it. Where a request reaches us directly, we will pass it to the client and tell the person that we have done so.

Florida residents. The Florida Digital Bill of Rights applies to controllers with more than $1 billion in global gross annual revenue. We are far below that threshold, so it does not apply to us. We describe our practices here anyway, because the size of a company is not a reason for the people it serves to be told less.

Security incidents

If personal data is exposed in a way that puts anyone at risk, we will tell affected clients without undue delay and in any case within 72 hours of becoming aware, with what happened, what was affected, and what we are doing about it. We will not wait until we understand it completely before saying something has happened.

That 72-hour commitment is deliberately shorter than what the law requires of us. As a third-party agent holding personal information on behalf of our clients, Florida law requires us to notify the client within 10 days of determining that a breach has occurred. Our clients then have their own statutory obligations, which for Florida residents include notifying affected individuals within 30 days and, for breaches affecting 500 or more Florida residents, notifying the Florida Department of Legal Affairs. We will give clients the information they need to meet those deadlines, and in time to be useful.

Children

Ledgerline is a business service. It is not directed at children and we do not knowingly collect personal data from anyone under 18.

Changes

Material changes are announced to clients before they take effect. The date at the top of this page is the last time it changed, and the version history lives in our source repository alongside the software it describes.

Contact

support@vantrelco.com Vantrel Consulting LLC · State of Florida, United States