Data Processing Addendum — Ledgerline

Vantrel Consulting LLC · Last updated: 19 September 2026

This Addendum forms part of the Terms of Service between Vantrel Consulting LLC, a Florida limited liability company ("Vantrel", "we", "processor"), and the client identified in the Order Form ("Client", "you", "controller"). It governs our processing of personal data on your behalf.

Where this Addendum conflicts with the Terms of Service or the Privacy Policy, this Addendum controls as to the processing of personal data.

1. What the words mean

Personal data means information relating to an identified or identifiable person that we process on your behalf under the Terms. In practice this is the contact details, names, email addresses and correspondence that appear inside your accounting records and your accounts payable mailbox — including those of your own vendors, customers and staff — together with the account details of people you authorise to sign in.

Processing means anything done with personal data: reading it, storing it, transmitting it, deleting it.

Controller and processor carry their ordinary meaning under applicable data protection law. Under US state privacy laws that use different words, you are the business and we are the service provider.

Sub-processor means a third party we engage to process personal data on your behalf. They are listed in Annex C.

Applicable data protection law means the privacy, data protection and data security laws that apply to each of us in respect of the personal data, including Florida's Information Protection Act, the California Consumer Privacy Act as amended, and any other state or national law that applies to you or to us.

2. Who is who

You are the controller of the personal data. You decide what to connect, for what purpose, and for how long. You are responsible for having a lawful basis for that processing and for having told the people concerned whatever you are required to tell them.

We are the processor. We process personal data only to provide the service to you, and only on your instructions.

3. What we may do with it, and what we may not

We process personal data only on your documented instructions. Your instructions are: the Terms of Service, this Addendum, your Order Form, the configuration you set inside the service, and anything else you tell us in writing. We will not process personal data for any other purpose.

If we believe an instruction from you would breach applicable data protection law, we will tell you rather than carry it out silently. If we are required by law to process personal data other than on your instructions, we will tell you before doing so unless the law forbids us from telling you.

We specifically will not:

• sell personal data, or share it for cross-context behavioural advertising;
• retain, use or disclose personal data for any purpose other than performing the service for you, or outside the direct business relationship between us, except where applicable law requires it;
• combine personal data received from you with personal data received from anyone else, except as necessary to perform the service for you;
• use personal data to train, fine-tune or evaluate machine learning models;
• use one client's personal data to provide, improve or develop the service for another client.

Certification. We certify that we understand the restrictions in this section and that we will comply with them.

4. Confidentiality

Everyone we allow to process personal data is bound by a duty of confidentiality and only has access where they need it to do their job. Vantrel is currently a single-member company operated by one person; where that changes, this obligation applies to anyone added.

5. Security

We implement and maintain appropriate technical and organisational measures to protect personal data against accidental or unlawful destruction, loss, alteration, unauthorised disclosure and unauthorised access. Those measures are described in Annex B, which is a description of what the software actually does rather than a statement of aspiration.

We will not materially reduce the protections in Annex B during the term.

6. Sub-processors

You give us general authorisation to engage the sub-processors listed in Annex C. Each is engaged under a written contract that requires it to protect personal data to a standard no less protective than this Addendum, and we remain fully responsible to you for what our sub-processors do with your personal data.

Adding one. We will give you at least 30 days' notice before adding or replacing a sub-processor. If you reasonably object on data protection grounds within that period, we will work with you to find an alternative; if we cannot within a further 30 days, you may terminate the affected part of the service without penalty and we will refund fees for the unused period.

Note that Anthropic, Intuit and Microsoft are not optional. The service cannot be provided without them, so an objection to one of those three is, in practice, an objection to the service.

7. Helping you answer people who ask

Taking into account the nature of the processing, we will assist you with appropriate technical and organisational measures in responding to requests from people exercising their rights under applicable data protection law — access, correction, deletion, portability, objection.

Where such a request reaches us directly and concerns your data, we will not answer it ourselves. We will pass it to you promptly and tell the person we have done so.

Where the request concerns data we hold as controller — your own users' account details — we answer it ourselves.

8. Helping you with your own obligations

We will provide you with reasonable assistance in meeting your obligations regarding security of processing, notification of personal data breaches, data protection impact assessments, and consultation with a supervisory authority, taking into account the nature of the processing and the information available to us.

9. Personal data breaches

What we will do. We will notify you without undue delay and in any case within 72 hours of becoming aware of a personal data breach affecting personal data we process on your behalf. That notification will describe, so far as we know it at the time:

• what happened and when we became aware of it,
• the categories and approximate number of people and records affected,
• the likely consequences,
• what we have done and are doing about it, and
• who to contact for more.

We will not delay telling you because we do not yet have the full picture. We will send what we know and follow up.

Why 72 hours. Florida law requires a third-party agent that maintains, stores or processes personal information on behalf of a covered entity to notify that entity within 10 days of determining that a breach has occurred. Our 72-hour commitment is deliberately shorter, because your own statutory clocks start running when you find out, and ten days of ours would consume a third of yours.

What you will need to do. Notifying affected individuals and any regulator is your responsibility as controller, because they are your records and your relationships. For Florida residents that generally means notice to individuals within 30 days of determination, and notice to the Florida Department of Legal Affairs where 500 or more Florida residents are affected. Other states and countries differ. We will give you what you need to meet those deadlines, and we will not make you ask twice.

We will not make a public statement identifying you in connection with a breach without your prior written consent, unless we are legally required to.

10. Getting your data back, and deleting it

During the term, you can export your data from the service at any time, and we will help if the export you need is not one the interface offers.

On termination, we delete personal data as follows:

We will certify deletion in writing if you ask.

The exception is anything we are required by law to keep, which we will keep only for as long as required and only for that purpose, and which remains subject to this Addendum while we hold it.

11. Audit

We will make available to you the information reasonably necessary to demonstrate compliance with this Addendum, and will respond to a reasonable security questionnaire once per twelve-month period.

You may audit our compliance on 30 days' written notice, no more than once per twelve-month period unless a breach has occurred, during business hours, in a manner that does not unreasonably disrupt the service, and subject to confidentiality. You bear your own costs of an audit. An audit may not extend to another client's data, and we will refuse any request that would expose it.

12. International transfers

Personal data processed under this Addendum is stored and processed in the United States. We do not transfer it outside the United States, and we do not engage sub-processors to process it outside the United States.

If that ever changes we will notify you in advance under section 6 and put an appropriate transfer mechanism in place before any transfer occurs.

13. Liability

Each party's liability under this Addendum is subject to the limitations and exclusions in section 10 of the Terms of Service, including the higher cap that applies to breaches of our security and confidentiality obligations.

14. Duration

This Addendum applies for as long as we process personal data on your behalf, and its confidentiality, deletion and liability provisions survive termination.

Annex A — What is processed, and why

Subject matter. Provision of the Ledgerline service: working in a client's accounting records and nominated mailbox to check supplier invoices, keep track of and remind the client's customers about what they owe, forecast cash, review spending and summarise the client's finances weekly; making the specific changes to the accounting records that a person at the client approves; and presenting anything requiring a decision to a person at the client.

Duration. For the term of the Terms of Service, plus the deletion periods in section 10.

Nature and purpose of processing. Collection, reading, storage, structuring, analysis and presentation of invoice and accounting data, for the purposes of:

• identifying duplicate bills, unknown vendors, mismatches against purchase orders, changes to vendor payment details, and other matters requiring a human decision before a payment is made;
• tracking what the client's customers owe, and sending those customers reminders and statements from the client's mailbox, in the client's wording — routine reminders on the client's timetable unless the client switches that off, and every other email only as a person approves it;
• forecasting the client's cash, reviewing its spending, finding what needs cleaning up in its books, working through its month-end close, tracking its filing deadlines and preparing data for them, helping it plan from its own history, and summarising its finances;
• making, on a person's approval of each one, the changes to the accounting records listed in Annex B.

Categories of data subject.

• The client's own personnel who sign in to the service.
• The client's vendors and suppliers, and individuals at those vendors whose names, email addresses and correspondence appear on invoices or in the connected mailbox.
• The client's customers, and individuals at those customers, whose names, email addresses and invoice and payment details appear in the accounting records, and to whom reminders and statements may be sent.
• Payees of the client's card, check and cash purchases.
• Any individual whose personal data appears incidentally in the connected mailbox or accounting records.

Categories of personal data.

• Account data: name, business email address, password (as a scrypt hash), session identifiers (as SHA-256 hashes), sign-in activity.
• Business contact data appearing in accounting records: vendor and customer names, contact names, addresses, email addresses, telephone numbers.
• Correspondence: the content of messages and attachments in the nominated accounts payable mailbox, which may contain personal data chosen by the sender.
• Transaction data: invoice amounts, dates, reference numbers, purchase order references, payment records, purchases and their receipts, held in the client's accounting system.
• Outbound correspondence: the recipient, subject and text of every reminder or statement sent to a client's customer, kept whole as the record of what was said on the client's behalf.

Special categories of personal data. None are sought. The service does not request or require them. Where a sender includes such data in an email or an attachment, it is processed only incidentally and to the same standard as everything else.

Frequency. Continuous while the service is running: the mailbox is polled on a schedule the client sets, and the accounting system is read when a review runs — started by a person, by arriving invoice mail, or at times the client has scheduled — or when a person views the client's data. Changes to the accounting records and emails to customers happen one at a time, as each is approved or allowed.

Annex B — Technical and organisational measures

These describe the software as built. Each is implemented in code and, where noted, is covered by an automated test.

Access control and tenant separation. Every request is scoped to one client by that user's own account record; a client user cannot change which client's data a request touches, and the request is not consulted on the point. Verified by an automated test that was confirmed to fail when the scoping is removed.

Credential encryption. Credentials for connected systems are encrypted at rest with AES-128-CBC and HMAC-SHA256 authentication. The encryption key is supplied by environment variable and held outside the database, so a copy of the database — a backup, a stolen disk — does not yield credentials. Key rotation is supported. If no key is configured, the system refuses to store a credential rather than storing it unencrypted.

Per-client credential isolation. Credentials are stored per client, keyed on client and provider. One client's connection cannot be used to reach another's data.

Authentication. Passwords are hashed with scrypt. Only a SHA-256 hash of a session token is stored, so a copy of the session table does not permit sign-in. Sessions expire. Sign-in attempts are rate-limited. Accounts can be revoked and passwords reset by an operator, and a reset ends every existing session.

A user of a client may also ask for a password reset themselves. The link is emailed from that client's own mailbox to the address the user signs in with, only a SHA-256 hash of it is stored, it can be used once, it stops working an hour after it is sent, and asking for a new one invalidates any earlier one. The number that can be requested for an address is limited. Completing a reset ends every session that account had open and does not disable two-step sign-in, so access to the mailbox alone does not give access to the account. Operator accounts cannot be reset this way.

Transport security. All traffic is served over TLS. Session cookies are HttpOnly, SameSite=Lax and marked Secure. HTTP Strict Transport Security is enforced. A Content Security Policy restricts what the browser will execute.

Least privilege on connected systems. Reading and writing are separate. The component that reads the accounting system cannot write: an automated test enumerates its entire public surface and asserts that only one internal function reaches an accounting host and that it never sets an HTTP method.

Writing lives in one other component, which can perform exactly seven operations — create a bill, create a vendor credit, attach a document to a bill or vendor credit (and to nothing else), create a journal entry, create an invoice, ask QuickBooks to email an invoice, and move one purchase line to another account — against seven fixed paths. An automated test enumerates both and fails if either grows; the same test asserts that no operation exists to delete or void. Each operation is built by the server, never supplied by an agent, and:

• runs only if writing has been switched on for that client (off by default; switched on by the operator at the client's request; the client can switch it off);
• runs only after a person at the client approves that specific change, having been shown what it will be;
• is rebuilt from the client's records at the moment of approval and not made if anything it depends on has changed since;
• is read back afterwards, and recorded as uncertain rather than done if it does not read back as approved.

Changing a purchase's category is built from the purchase as just read, so the only difference it can send is that one line's account, and QuickBooks refuses it if the purchase changed in between. Only lines in an uncategorised account can be moved, and nothing dated in a period the client's books are closed for.

The mailbox integration holds Mail.Read, and — only for clients who use customer reminders — Mail.Send. The client is advised and assisted to scope both to a single mailbox. Sending is confined to one component that sends one plain-text message to one address, with no attachments and no copies, pinned by an automated test. The address is the one the client's accounting system holds for that customer, never one an agent supplies; the text is built by the server from the client's own templates. Each email is approved by a person unless the client has allowed that routine stage to go automatically; a final notice, and any email with added words, always needs a person.

Handling of untrusted content. Content arriving from outside — invoices, email bodies, attachments, text written on transactions — is treated as data and never as instruction. Instructions found inside a document are reported to the reader, never executed. Any change to a vendor's payment details is escalated to a person at any amount, because that is the fraud pattern that value thresholds do not catch. Documents are parsed in an isolated child process under a wall-clock deadline and a size limit.

Logging and redaction. Requests and failures are logged server-side. Credentials are never logged: anything credential-shaped is replaced with its length before any diagnostic output.

Change control. The agents' configuration is version-controlled and pinned per run, and the running configuration is continuously compared against the repository; a mismatch is reported in four places rather than hidden. All changes are recorded in a source repository.

Backups. The database is backed up nightly. Every backup is verified before it is kept — structural integrity, presence of the tables that carry financial records, and a row count recorded beside it so a silently truncating backup is noticed rather than discovered.

Each backup is kept on the server for 30 days, and a copy is sent to storage held by a second provider, where it is kept for 90 days, so the loss of the server is not the loss of the records.

That copy is encrypted with a public key before it leaves, and the corresponding private key is not held on the server: the machine can add to the archive and cannot read it back. The credential used to upload cannot delete — confirmed against what the storage provider reports that credential is permitted to do, not only against what was requested — so an attacker who reaches the server cannot erase the backup history. Retention is enforced by the storage provider as a lifecycle rule instead. The key that encrypts stored client credentials is not in the backups and is not in that storage.

A restore from the offsite copy has been carried out end to end — downloaded, decrypted, unpacked and verified against the live row counts — rather than assumed to work.

Testing. The security-relevant behaviour above is covered by an automated suite of over 1,200 checks run before changes ship, including tenant isolation, credential handling, session handling, the handling of hostile documents, and every guard on writing and sending. Each guard on a write or a send has been removed in turn and confirmed to make a check fail. Four rounds of adversarial security review were run against the invoice-reading path, and every finding was fixed with a regression test confirmed to fail without the fix.

Organisational measures. Access to production systems is limited to Vantrel's operator, over SSH with key-based authentication and passwords disabled, with multi-factor authentication on every account that holds a credential reaching client data.

Annex C — Sub-processors

Intuit and Microsoft are the client's own providers as well as ours; data reaching them is data returning to the system it came from.

The current version of this list is always the one published at https://vantrelco.com/dpa.

Contact

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