Privacy policy

1. Controller and contact details

The controller of your personal data is Jānis Palde, a sole trader.

The controller's legal address is "Rozītes - 11", Brandeļi, Kocēnu pagasts, Valmieras novads, LV-4220, Latvia.

The controller's business (taxpayer) registration number with the State Revenue Service is 07119811356.

For questions about the protection of personal data, please use the email address info@erekini.eu.

2. Data processing roles (important)

To operate the Platform, we act in two different roles depending on the type of data:

A. We as controller. For your data as a User, namely your email, password and company details, we determine the purposes and means of processing.

B. We as processor. For the data you enter on invoices, namely your clients' names, addresses and descriptions of goods, you are the controller and we are only the processor providing the technical infrastructure, and we process that data solely on your instructions, which follow from your use of the Platform.

3. What information do we collect?

3.1 Data you provide to us.

• Account data, namely email, password (in encrypted form), first name and surname.
• Language choice, namely whether you use the Platform in Latvian or in English, so that we send you our emails in the same language.
• Signing in with Google. If you register or sign in with a Google account, Google passes us your name, email address and a link to your profile picture. We do not see your Google password.
• Billing data. Payments are processed by Stripe. We keep the Stripe customer and subscription identifiers, the chosen plan, payment status, dates and amounts. We do not receive or store the card number, expiry date or security code.
• Communication, namely email correspondence with support.

3.2 Data collected automatically.

• Technical data, namely IP address, browser type, device type and sign-in times (access logs for security purposes).
• Usage data, namely records of which Platform features and pages you use (for example, "invoice created" or "stock opened"). These records are linked to your account, contain no invoice or client content, and we use them to improve the Platform. When you sign up, we also keep which page or link of our website brought you to the sign-up, so that we know which pages people find useful.
• Visit statistics, namely page view counts and loading speed, produced without cookies by Vercel Web Analytics and Speed Insights. These tools do not identify you or follow you across days or other websites.

3.3 Data you enter into the system (content data).

Information needed to generate invoices (your clients' details, bank accounts, descriptions of goods/services) and, if you use the "Stock" add-on (Noliktava), your product catalogue, stock data, and reservation and online shop order data (see section 5.3). If you keep the income and expense journal, the Platform also stores your bank statement data, the journal entries and the tax regime you stated (see section 5.9).

3.4 Conversation data (the AI assistant "Laima").

• Conversation history, namely, to give answers in context, we keep your conversation with the assistant, and you may delete this history at any time in your settings.
• Sensitive data, namely, we ask you not to enter in conversations with the assistant sensitive personal information that is not needed for accounting purposes, such as health data or passwords.

4. Purposes of processing and legal bases

We process data on the legal bases listed below.

• Performance of a contract, namely to give you access to the Platform, generate invoices, manage subscriptions and provide technical support.
• Compliance with legal obligations, namely meeting accounting and tax requirements for the invoices we issue to you.
• Our legitimate interests, namely keeping the system secure, preventing errors and fraud, and analysing the usage data and visit statistics described in section 3.2 to improve the Platform, to the extent that this does not infringe your fundamental rights and freedoms.
• Messages to existing Users, namely emails about Platform news, similar services of ours and offers, which we send to you as our customer under Section 9(2) of the Law on Information Society Services. You may opt out of them at any time using the link in each email or the email settings on the Platform, and opting out does not affect invoice, security and account notices.
• Your consent, namely where we use advertising cookies (see section 9), send our newsletter to people who are not our customers, or where you have switched on the artificial intelligence features (see section 5.2); you may withdraw consent given in this way at any time, without affecting the lawfulness of processing carried out before withdrawal.

5. Recipients of data (third parties)

We do not sell your data or pass it to third parties for their own marketing purposes. Data is passed to Google and Meta to measure advertising effectiveness only with your consent (see section 9). To provide the Service, we use trusted partners (sub-processors).

The table below lists the sub-processors we engage to provide the Service and for whom we are responsible under section 5 of the Data Processing Agreement. Separately from these, the User may choose to use the services of its own service provider, in which case we pass data to that service provider on the User's instructions, but it is not our sub-processor and acts on the basis of its own contract with the User. At present this applies only to accepting card payments in the User's online shop through the User's own Stripe account, described in section 5.3.

Where data is transferred outside the EU or EEA, we ensure appropriate safeguards, in particular standard contractual clauses (SCC) approved by the European Commission, or transfers to countries for which the European Commission has adopted an adequacy decision.

For artificial intelligence features, including the assistant "Laima", we use the Claude application programming interface provided by Anthropic (Claude API) under Anthropic's commercial terms. The following Platform features are provided through this interface:

• document digitisation (OCR) and extraction of invoice or expense data from uploaded documents, photos and email texts, including suggesting expense categories;
• drafting payment reminders, including choosing the language and tone of communication;
• reading bank statements (PDF) and extracting transaction data;
• detecting signs of fraud in received invoices and assessing business partner risk, including analysis of public data of the State Revenue Service;
• cash flow forecasts, checking tax and VAT reports, recognising fixed assets, drafting the management report of the annual report, analysis of business health, prices and financial reports, and monthly accounting audit reports;
• Laima's morning review: where the User has switched the assistant on and the User's plan includes it, the company's invoice, bank payment, subscription and tax deadline data is reviewed every morning, and the items to be done that the software has found, together with the facts they concern (for example the client's name, the invoice number, the amount and the due date), are passed to the assistant so that it can put them in order, write a short explanation for each and draft payment reminders;
• conversations with the assistant "Laima", in which the User's invoice, client and financial data are passed to the assistant as context so that it can answer the User's questions.

Under Anthropic's commercial terms, which the User can read at anthropic.com, Anthropic may not use the data and documents you send to train models, and they are processed confidentially solely for the purpose of providing the service to you. Anthropic deletes requests and responses within 30 days; it keeps them longer, for up to two years, only if Anthropic's automated safety systems flag a request as a possible breach of its usage policy, or where the law requires it. Our contracting party is Anthropic Ireland, Limited, but the interface is technically provided on Anthropic's global infrastructure, including the USA, so data is transferred outside the EU and EEA on the basis of the standard contractual clauses (SCC) approved by the European Commission that are included in Anthropic's data processing addendum.

5.1 Additional information on Peppol e-invoice delivery

At present, invoice data is not passed to any e-invoice delivery network operator. The Provider has no active access point (Access Point) or connection to any other delivery network operator, so sending e-invoices through a network is not provided on the Platform, and this section only describes what would happen if such functionality were activated.

Creating and downloading a structured e-invoice does not mean passing data to a third party. The invoice XML file is prepared on the Platform and is available for the User to download. What the User does with the file next, including whether it submits it to its official electronic address (e-adrese), in the Electronic Procurement System or passes it to a business partner through another channel, is the User's own action, and the Provider takes no part in that transfer and does not pass the data on.

Data that would be passed if the functionality were activated. When an e-invoice is sent through a delivery network, the operator concerned would receive the invoice XML document containing the seller's and buyer's details (name, registration number, VAT registration number, address and contact details, to the extent the User has included them on the invoice), the invoice lines, amounts, currency, payment terms and invoice identifiers.

Transfer of data to the invoice recipient. After the invoice is submitted to the delivery network, the same invoice XML would be passed to the recipient (the User's client) or to its access point. This transfer of data is an integral part of the functionality concerned and would follow from the User's instruction to send the invoice to a specific addressee. The User takes responsibility for the accuracy and completeness of the data included on the invoice and for its suitability for the purpose of sending.

Notice before activation. The Provider will not activate sending e-invoices through a delivery network without first updating this Privacy Policy and adding the operator concerned to the list of sub-processors, stating its name, the purpose of processing, the location of the data and the legal basis for transfer. Until then, the User's invoice data is not passed to any such operator.

5.2 Artificial intelligence transparency and human oversight (EU Artificial Intelligence Act)

Information about interacting with artificial intelligence. The assistant "Laima" is an artificial intelligence system that works through the Anthropic Claude application programming interface (Claude API). When communicating with the assistant, the User is interacting with artificial intelligence, not with a human.

Content generated by artificial intelligence. The answers, analyses, classifications, forecasts and drafts prepared by the assistant, including drafts of payment reminders, are content generated by artificial intelligence.

Human oversight. Reminder and invoice drafts prepared by artificial intelligence are by default prepared for the User to review and approve before anything is sent. Risk flags, fraud warnings, forecasts and analyses are decision-support information, and the decision is made by the User. No decision producing legal or similarly significant effects for the User or for data subjects is taken solely on the basis of automated processing within the meaning of Article 22 of the General Data Protection Regulation.

Control. Artificial intelligence features are switched off by default. They work only after the User switches them on in the "Laima" section of the settings, and until then none of the User's content is passed for artificial intelligence processing. The User may switch them off again at any time, and the passing of data then stops immediately. Drafts prepared by artificial intelligence are by default sent only after the User's approval. The User may also ask for a matter to be reviewed by a human by contacting us at the email address given in section 1.

Applicability. These transparency obligations arise from Article 50 of Regulation (EU) 2024/1689 of the European Parliament and of the Council (the Artificial Intelligence Act), whose requirements apply from 2 August 2026.

5.3 Stock: sales, receipts, gift cards, purchasing and B2B orders

Data processed. If the User uses the "Stock" add-on (Noliktava), the Platform stores the User's product catalogue, namely product names, descriptions, barcodes, sale and cost prices and stock levels, the stock movement history, quick sale transaction records (receipts), data on gift cards issued by the User, namely the card code, value, balance, expiry date, design and history of actions, and, if the User runs a loyalty programme, the data of its members described later in this section. This data is the User's content data within the meaning of point B of section 2 of this policy, which means that the User is its controller and we are the processor.

Buyer data in quick sale. Quick sale is anonymous by default, meaning that the buyer's personal data is not needed to complete the transaction, is not requested and is not collected, and the transaction is recorded without identifying the buyer. If, at the buyer's request, the User enters the buyer's email address to send the receipt, that address is used only to send that receipt once, through our email sub-processor (Zoho, see the table in section 5), and it is not added to the User's client register, not used for marketing and not processed for any other purpose. For this processing too, the User is the controller and we act as processor. Buyer data that the User records, at the buyer's choice, in connection with gift cards or the loyalty programme is described later in this section.

Barcode scanning with the camera. Barcode scanning uses the camera of the User's device, and access to it is obtained only after the User has allowed it in the browser. The camera image is processed locally on the User's device to recognise the barcode, and the video stream or images are not transmitted to our servers or those of third parties and are not stored. Only the value of the recognised barcode is sent to our server, to find the product concerned in the User's catalogue. The User may withdraw access to the camera at any time in the browser settings.

Payment QR code. The quick sale payment QR code contains the payment details given by the User, namely the beneficiary's name, IBAN account number, payment amount and payment reference; it is generated when displayed and is not stored on our servers. We receive no information about the buyer's identity, the buyer's bank account or the execution of the payment, as the payment is made directly between the buyer and the User through their banks.

Receipt download link and storage. The receipt download link is a cryptographically signed link giving access only to the PDF document of that specific receipt, and it is accessible to anyone who obtains it. The receipt shows the User's details, the goods sold and the amounts, but not the buyer's personal data. The link remains valid for as long as the User's account and the transaction record concerned exist, so that the buyer can also obtain their proof of purchase later. The receipt QR code is generated at the time of the transaction and is not stored on our servers, while the transaction record itself (the receipt) is subject to the retention periods set out in section 7.

Gift cards. If the User issues a gift card to a buyer and the buyer gives their email address to receive the card, that address is stored with the card record so that the card can be resent at the User's request, and it is not used for any other purpose, including marketing. A digital gift card is available through a cryptographically signed link showing the User's name, the card balance, the code and the expiry date, but not the buyer's personal data; the link is accessible to anyone who obtains it, and it ceases to be valid if the User reissues the card with a new code or cancels it. The digital card page uses no cookies and does not track visitors. The User is the controller of this data, we are the processor, and gift card records are subject to the retention periods set out in section 7.

Loyalty programme. If the User runs a loyalty programme, the Platform stores the telephone number of the User's client, their name if given, the time their consent was recorded, their balance, and summary data relating to purchases, namely the number of purchases, the total amount of purchases and the time of the last purchase. The User collects this data from its client and must inform the client and obtain their consent before registering them; the User is the controller of this data, while we are the processor, processing it solely to operate the programme. We do not use this data for our own purposes, including marketing, and do not pass it to third parties, except the infrastructure sub-processors named in the table in section 5. The User's client exercises their data subject rights, including the rights of access and erasure, by contacting the User (the shop) concerned, and the Platform allows the User to delete the client's data and the history associated with it irreversibly and immediately.

Balance link for the client. The User may create a cryptographically signed link on which its client sees their balance, the total amount earned, the number of purchases and the earning rate, and their name if the User has given it. The link does not contain the client's telephone number or purchase history, uses no cookies and does not track visitors. The User gives the link to the client, and we do not send it automatically. The link is accessible to anyone who obtains it and ceases to be valid if the User reissues it.

Reservations. If the User reserves goods for a specific buyer, the Platform stores the buyer's name and telephone number, if the User has given them, and the reserved goods, quantity, price at the time of reservation, the period, and the way of collecting the goods chosen by the buyer, with a note if the buyer has added one on the reservation page. The User collects this data and must inform its buyer; the User is the controller of it, while we are the processor. The reservation page uses no cookies and does not track visitors, and stock levels and cost prices are not visible on it.

Online shop and orders. If the User publishes its product catalogue in a public shop, to submit an order the buyer gives their name and email address and, depending on the chosen way of receiving the goods, a telephone number and a delivery address or the name of a parcel locker, and a note for the order. This data goes to the User's list of orders and is used solely to fulfil that specific order; it is not used for marketing, and we send the buyer nothing automatically. The User is the controller of this data, while we are the processor, and the buyer exercises their data subject rights by contacting the User (the shop) concerned. The shop page uses no cookies and does not track visitors, and the contents of the basket are stored, until the order is sent, only in the buyer's own browser.

Card payments in the shop. If the User has activated card payments in its online shop, they are made through the User's own Stripe account. When a payment is started, on the User's instructions we pass to Stripe the buyer's email address (so that Stripe can send a payment confirmation), the names and amounts of the order lines, and the order identifier. The buyer enters the card details on a payment page run by Stripe, not on our Platform, so we do not receive or store the card number, expiry date or security code. From the payment, we keep only the Stripe payment session identifier, the payment status, the time of payment and the amount, so that the User can see that the order has been paid. We do not collect, receive or hold the money: it goes directly to the User's Stripe account. For this processing, in our relationship with the User, the User is the controller, while we are the processor, passing data solely on the User's instructions. As regards payments in the User's shop, Stripe is not our sub-processor: it acts on the basis of the contract between the User and Stripe, the User itself chooses to engage it, and we are not responsible for Stripe's processing of data in these payments. Stripe provides information about this in its privacy policy, and the User must inform its buyers of this transfer of data.

Shop product images. Product images uploaded for the shop are stored in a publicly accessible file store with our infrastructure sub-processor (Supabase, see the table in section 5), and they are accessible to anyone who has the address of the image concerned, even after the product is no longer shown in the shop. The User is responsible for the content of the images and for whether they may be made public, and images the User does not want to be publicly accessible need not be uploaded.

Company logo. If the User uploads its company logo, it is stored in a publicly accessible file store with our infrastructure sub-processor (Supabase, see the table in section 5) and is accessible to anyone who has the address of the image concerned. This is technically necessary for the logo to appear in invoice PDF files, in emails and in public invoice links, which the User's client opens without authentication. We convert the uploaded image to a uniform format, reduce its size, delete the file's metadata (including any capture data) and may prepare versions of the image with a single-colour background removed and a light version for use on a dark background. A logo usually contains no personal data, but it may, for example where a sole trader uses their own name or photograph; in that case the legal basis for processing is performance of a contract, namely the document design requested by the User. The logo is replaced when the User uploads a new one, and is deleted together with previous versions when the User removes it or when the User's account is deleted. Images the User does not want to be publicly accessible need not be uploaded.

Recipes and production. If the User uses the recipe and production features, the Platform stores the product compositions specified by the User, the quantities of raw materials used, production run records, batch labels and the calculated cost prices. This is data about the User's business, and it contains no personal data unless the User has entered such data itself in free-text fields.

Purchasing and supplier data. If the User uses the purchasing features, the Platform stores the User's supplier catalogue, namely the supplier's name, registration and VAT number, email address, telephone, address, bank account number, delivery time and the User's notes, as well as the orders to suppliers prepared by the User and the history of their receipt. To the extent that a supplier's contact information contains data of a natural person, for example a contact person's email address, it is entered on the Platform by the User, who is the controller of that data, while we are the processor. An order is emailed to a supplier only after a direct action by the User. Stock radar suggestions and profit reports are calculated solely from the data the User has recorded on the Platform, and these calculations are not used for any other purpose. If the User has switched on the optional weekly stock summary on the Platform, an email with suggested orders is sent to the address the User has given; the User may switch this option off at any time in the same place on the Platform.

B2B ordering portal. If the User creates a B2B ordering portal link for its client, the User's catalogue of active products is visible through it without authentication, with prices including the discount granted to that client, but not stock levels or cost prices. When an order is submitted, the content of the order is stored, together with the contact person and notes the client has chosen to give; the contact person's name is personal data of which the User is the controller, while we are the processor, processing it solely to handle the order. The portal page uses no cookies and does not track visitors; the portal link is accessible to anyone who obtains it until the User suspends or reissues it, and it stops working automatically if the add-on subscription is no longer active. The User is notified of a new order on the Platform and at the email address the User has given on the Platform. Order records are subject to the retention periods set out in section 7.

Delivery to a parcel locker or by courier

List of parcel lockers and pick-up points. So that the buyer can choose a specific parcel locker or pick-up point when placing an order, the Platform uses the carriers' (Omniva, Venipak) publicly available lists of points, which give each point's name, address, postcode, coordinates and opening hours. These lists contain no personal data, are accessible to anyone without authentication, and we keep them on our side only so that searching is fast. The User needs no contract with a carrier to use this feature, and no data is passed to a carrier at this step.

Registering a shipment under the User's own carrier contract. If the User adds the credentials of its own carrier contract account on the Platform and registers a shipment, on the User's instructions we pass to the carrier concerned the data needed to process the shipment, namely the recipient's first name and surname, telephone number and email address, the identifier of the chosen parcel locker or pick-up point or the delivery address, and the weight of the shipment. The carrier processes this data on the basis of its contract with the User, and it is not our sub-processor within the meaning of section 5 of this policy, in the same way as described for accepting card payments through the User's own Stripe account. We are not a postal or courier service provider, we do not sell postal services and take no fee from them; the User pays for the shipment directly to the carrier.

Carrier credentials. The credentials of the User's carrier contract account (username, password and customer code) are stored in encrypted form, are not returned in any Platform response and are not visible in the Platform interface; the User may disconnect them at any time, in which case they are irreversibly deleted. We use this data solely to create a shipment on the User's instructions, to receive the shipping label prepared by the carrier and to receive shipment status updates.

Shipment data and tracking. The shipment record stores the recipient's name, telephone number, email address and delivery address or chosen parcel locker, the shipment number assigned by the carrier, the shipping label prepared by the carrier, and the shipment status history received from the carrier. The name and address of the chosen parcel locker are saved when the order is placed and are not overwritten later, so that it remains visible over time which point the shipment was actually sent to. The User is the controller of this data, we are the processor, and it is subject to the retention periods set out in section 7. Notifications about the progress of the shipment are sent to the buyer by the carrier under its own terms, not by us.

Cash on delivery is not offered. The Platform does not support collecting payment on receipt of the shipment (cash on delivery), and no such option is passed to the carrier. The buyer pays for the order by transfer or by card before the shipment is sent.

Multiple stock locations and picking. If the User uses several stock locations, the Platform stores each location's name, label and the stock of products at each location, while the picking check processes only product barcode values. Neither involves processing personal data.

5.4 Received invoices between users of the Platform

What happens. If a user of the Platform issues an invoice stating the registration number of another user of the Platform, the invoice may be placed in the recipient's account as structured data. This is not a transfer of data to a third party outside the Platform: both parties are our users, the document is not sent anywhere, and no new sub-processor is involved in the process. Nor is it sending an e-invoice through a delivery network; section 5.1 applies to that.

How the recipient is determined. A registration number alone is not enough, as the Platform does not check it and anyone can enter it. An invoice is therefore placed in the recipient's account only if it is confirmed by data recorded independently by the invoice issuer, namely if the email address in the issuer's client record matches the address of the recipient's account or is on the same company domain. The purpose of this check is to prevent a document from reaching the wrong person, and its legal basis is our legitimate interest in keeping the Platform secure within the meaning of Article 6(1)(f) of the General Data Protection Regulation. If there is no confirmation, the invoice is not placed in any account and no one is informed of it.

Storage of the received copy. A copy of the invoice is kept in the recipient's account in the form in which it was issued, namely the invoice number, dates, amounts, lines, the issuer's details and payment information. For this copy the recipient is the controller and we are the processor, as for the rest of the recipient's content data. The copy is not overwritten if the issuer later corrects its invoice, as the recipient's accounting record must not change without the recipient's knowledge.

What the invoice issuer learns. If the recipient books or declines the invoice, the issuer is shown that fact, the name of the recipient's organisation and the time of the action. The issuer sees nothing of the recipient's accounts. This information is given because it follows from the recipient's deliberate action concerning a specific issuer's document, and its legal basis is performance of the contract between the parties and our legitimate interests. If the recipient only receives the invoice and takes no action, the issuer is not told, and the Platform in no way reveals whether or not a particular company has an account on the Platform.

If the recipient is not a user of the Platform. If no user of the Platform corresponds to the registration number, we keep only a record that an invoice has been issued to that number, namely the normalised registration number and a reference to the issuer's invoice. The content of the invoice is not copied into that record, and the record is not disclosed to anyone. The record is deleted automatically within 12 months at the latest. These invoices are not automatically added to an account created later.

5.5 Invoice links and the record of invoice opening

What is recorded. When the User's client opens an invoice link sent by the User, we record the time of opening, device type, browser, operating system and browser identifier, and a hash of the IP address, which we use only to group repeated openings. While the page is open, the time spent on the page, how far the page was scrolled and whether the PDF was downloaded are also recorded. The IP address itself is not stored, and the page uses no cookies, advertising or analytics tools.

Purpose and roles. This information is seen only by the invoice issuer, so that it knows whether and when the invoice has been opened. The User is the controller of this data, while we are the processor, and the User must inform its clients of this. The records are kept for as long as the invoice concerned exists and are deleted together with it.

5.6 Forwarding invoices from email

What happens. On the Platform, the User may create an email address for its company to receive invoices, and set up its own email to forward messages to it, for example suppliers' invoices. Emails addressed to this address are received by Cloudflare (see the table in section 5) and passed immediately to our server. Cloudflare does not store the content of emails, but temporarily records the email's metadata in its activity log, such as the sender's and recipient's addresses and the delivery result. This is not receiving e-invoices through a delivery network; section 5.1 applies to that.

What is kept. From each email we keep only the attachments that may be invoices or receipts, namely PDF files, images and e-invoices in XML format, together with the sender's address and whether the email is signed on behalf of the sender's domain (DKIM). Each such document becomes an expense entry of the User in the "Received" section and is kept for as long as that entry exists; deleting the entry also deletes the file. The text of the email is not kept, and emails without such attachments are not kept at all. For each email received, a record with the time of receipt, the sender's address and the result is kept for 30 days, and for an email too large to be accepted, also its subject, so that the User can find it in its mailbox.

Reading documents. We read e-invoices in XML format without artificial intelligence. PDF files and images are read by the assistant "Laima", through the Claude API described at the start of this section, only if the User's plan includes it and the User has switched the assistant on; otherwise the file is kept and the User enters the data itself. The data read only fills in a draft expense entry, which the User checks and books itself.

Bank statements. If a bank account statement (in ISO 20022 camt, FiDAViSta or CSV format) is forwarded to this address from the email address of the organisation's owner, signed in that address's domain name, we import it as bank payments like an uploaded statement, and for the self-employed they become journal entries (section 5.9). Statements from other addresses are not imported.

Roles. Forwarded emails may contain personal data of the User's suppliers and other senders that the User chooses to forward. The User is the controller of that data, while we are the processor. The User may change or switch off the address at any time, after which emails to the previous address are not accepted and are returned to the sender.

5.7 Questions about invoice payment and the journal, and month end

What happens. When an invoice's due date has passed and the invoice has not been marked as paid, we email the invoice issuer or the owner of the company to ask whether the client has paid. On the Business plan, on the first working day of the month, we also send a list of what was left undone from the previous month. Both emails are notices about your own accounts, and you may opt out of them in the email settings.

What is kept. For each question we keep which invoice it concerned, whom it was asked and when, and what the answer was, so that we do not ask about the same invoice twice. The email contains a personal link; we keep only its hash, and the link stops working after 7 days. The invoice is marked as paid, and a reminder is sent to the client, only after your confirmation, and only someone who is still an owner or member of the company concerned can answer using the link. We do not keep the monthly list: it is calculated from your data each time, and the monthly check made before the email is sent is a calculation without artificial intelligence. Question and answer records are kept for as long as the invoice concerned exists and are deleted together with it.

Question about unclassified payments. For the self-employed, we may once a month send the organisation's owner an email asking about journal payments whose type we could not determine; the email shows each payment's date, counterparty, amount and purpose. For each email we keep which entries it was sent about and the hash of the link, and the link stops working after 14 days. An answer records the payment's type and remembers it for the same counterparty (section 5.9).

5.8 Document requests (the "Office" plan, Birojs)

What happens. A user on the "Office" plan may send a client company an email asking it to send documents for selected payments. The email contains the date, payee, amount and reference of the bank payments selected by the accountant, as well as the client company's invoice address (see section 5.6). We send the email in the office's name to the email address given by the accountant, and replies go to the accountant.

What is kept, and roles. We do not keep the recipient's email address. In the office's activity log we keep who sent the request and when, for which company and month, and how many payments it contained, and this record is kept for as long as the office account exists. For the client company's data, the office is the controller or acts on the client's instructions, while we are the processor.

5.9 Income and expense journal (for the self-employed)

Data processed. If the organisation is a natural person (self-employed), the Platform builds an income and expense journal from the User's bank statements. For each payment it stores the date, amount, direction, the counterparty's name and, where the statement has it, account number (IBAN), the payment purpose, the linked invoice or expense document and the type of entry, together with the tax regime stated by the User, its start dates and the marks of closed months.

Remembered rules. When the User chooses a type for a payment, the Platform may remember it for the same counterparty, keeping the counterparty's account number or name and the chosen type, and classify that counterparty's later payments automatically. The User sees these rules in the journal and may delete them or switch remembering off at any time. For received e-invoices the Platform likewise remembers the expense category by the supplier's registration number.

Importing from another tool. When a journal is imported from another tool, the file's content is read in memory and the file itself is not kept. We keep the file name, its checksum, the number of rows imported and skipped, and the period covered, so that the same file is not imported twice and the import can be undone.

Tax figures. The figures of the tax reserve, the quarterly VSAOI report, appendix D3 and the micro-enterprise tax are calculated from the journal, and we pass them to no one. If the User marks a quarter as filed, we keep the time of that mark.

Roles. The journal contains data of the User's counterparties, namely names and account numbers. The User is the controller of that data, while we are the processor. Journal data is kept for as long as the organisation exists and is deleted with the account (section 7).

5.10 VID tax account check

What happens. If the User enters its State Revenue Service EDS API key, we use it only for the requests of that check to the State Revenue Service's EDS application programming interface (eds.vid.gov.lv), to read the balance of the User's tax account and the payments of the year concerned. In this case the State Revenue Service is not our sub-processor: it is a public authority which we contact on the User's instruction with the User's own key.

What is kept. We do not keep the key, not even in system logs, and do not use it for other requests; after the check it is no longer in our hands. The data received from the State Revenue Service is only shown to the User and compared with the journal, and it is not stored in our database.

5.11 Link for the accountant

What happens. The owner of an organisation may create a link with which any person, without signing in, can view the organisation's income and expense journal, including counterparties' names, amounts and payment purposes, download it and open the files of the linked expense documents. The User passes the link on itself, and the User is the controller of that disclosure, while we are the processor.

What is kept. We do not keep the link itself, only its hash (SHA-256), together with the time it was created, expires and was revoked, and the day it was last opened, which the User sees. The link's pages are not indexed by search engines or cached, and the IP address of the person opening it is used only to limit excessive requests.

Validity. The link is valid for 12 months, and the User may revoke it at any time, after which it stops working immediately. The record of the link is kept for as long as the organisation exists.

5.12 Invoice designer

What is kept. If the User uses the invoice designer, the Platform keeps the User's designs, namely the name of the design, the placement of shapes, lines and text, the colours, the chosen fonts, the text written in the design and references to the images used in it. Images uploaded for a design are kept in publicly accessible file storage with our infrastructure sub-processor (Supabase, see the table in section 5) in a separate folder for the organisation, and are available to anyone who has the address of the image. This is technically necessary for the design to appear in invoice PDF files, emails and public invoice links. We convert an uploaded image to a single format, reduce its size and remove the file's metadata, including any location data from when it was taken. When an invoice is issued, a copy of the design is kept with the invoice so that the look of an issued invoice does not change later.

Personal data in a design. A design does not usually contain personal data, but it can, for example if the User places their signature, photograph or contact details in it. For the User's own data the purpose of the processing is to present the User's invoices in the look they have chosen, and the legal basis is the performance of the contract. If the User places another person's data in a design, the User is the controller for that data and we are the processor. Images whose public availability is not wanted do not need to be placed in a design.

Keeping and deletion. A design is kept until the User deletes it. Images used in designs are kept for as long as any issued invoice may show them, also after the design has been changed or deleted, and are deleted with the User's account as set out in section 7. The copy of a design kept with an invoice is kept for as long as that invoice.

The designer on the home page. On the Platform's public home page the logo editor and the invoice designer work only in the visitor's browser: the logo the visitor chooses and the design they draw are not sent to our servers and are not kept.

6. Data security

We apply up-to-date technical and organisational measures, covering the following.

• Encryption, namely all data is encrypted in transit using the TLS protocol, while two-factor authentication keys and third-party access keys added by the User are stored in the database in encrypted form.
• Access control, namely we use Row Level Security to ensure that each user can access only their own data.
• Backups, namely regular automated backups are made to prevent data loss.
• Processing of data by artificial intelligence, namely data is sent to the Claude API over encrypted channels, and Anthropic does not use it to train models. Anthropic deletes requests and responses within 30 days; it keeps them longer only if they are flagged as a possible breach of its usage policy.

In the event of a personal data breach that could pose a risk to your rights and freedoms, we notify the Data State Inspectorate without undue delay, in the cases and within the time limits set by legislation, and, if the breach could pose a high risk, we inform the persons concerned; where we process data on behalf of the User as controller, we notify the User concerned of such a breach without undue delay.

7. Data retention and deletion

• Active accounts. Data is kept for as long as your account is active.
• Account deletion. At your request, or after you press the "Delete account" button, the account is held ready for deletion for 7 days, so that a deletion made by mistake can be cancelled simply by signing in. After that, your data is irreversibly deleted from our active databases and file storage, and your Stripe customer record is also deleted (Stripe itself keeps transaction data to the extent its legal obligations require). In database backups, deleted data remains until the backups are overwritten, but for no longer than 30 days.
• Usage data. The usage records described in section 3.2 are deleted automatically after 13 months.
• Conversations with the assistant "Laima". Kept until you delete them; in the settings you may also choose not to keep conversations at all.
• Forwarded emails. The email receipt records described in section 5.6 are deleted automatically after 30 days, while documents saved from emails are kept for as long as the expense entry concerned exists.
• Questions about payment. The question and answer records described in section 5.7 are kept for as long as the invoice concerned exists, but the links in the emails stop working after 7 days.
• Questions about the journal. The link of the question about unclassified payments described in section 5.7 stops working after 14 days.
• Link for the accountant. The link described in section 5.11 stops working after 12 months or when revoked, while its record is kept for as long as the organisation exists.
• Invoice designs. The designs described in section 5.12 are kept until you delete them, and the images used in them for as long as any issued invoice may show them, and no longer than until the account is deleted.
• Accounting. Data about your payments to us, namely the invoices we issue to you, is kept for 5 years in accordance with the legislation of the Republic of Latvia.

Please note that deleting your account also deletes the invoices and client data you created, which you yourself may have to keep for the retention period for accounting documents set by legislation; before deleting your account we therefore recommend exporting and saving your documents using the data export feature available on the Platform.

8. Your rights

Under the General Data Protection Regulation, you have the rights listed below.

• To request access to your personal data and receive a copy of it.
• To request correction of inaccurate or incomplete data.
• To request erasure of data, namely to exercise the right to be forgotten, where the data is no longer needed for the purpose for which it was collected.
• To request restriction of processing in the cases provided for by legislation.
• To object to processing based on our legitimate interests, and to the use of data for direct marketing.
• To receive your data in a structured, commonly used and machine-readable format and transfer it to another controller, namely to exercise the right to data portability.
• To withdraw consent given earlier at any time, without affecting the lawfulness of processing carried out before withdrawal.

To exercise these rights, write to us at: info@erekini.eu. We reply within one month of receiving the request. You can also export your data and delete your account yourself in the Platform settings.

If you consider that your rights have been infringed, you have the right to lodge a complaint with the Data State Inspectorate (www.dvi.gov.lv).

9. Cookies

We use cookies and browser storage to make the Platform work and, only with your consent, to measure advertising effectiveness. We do not use analytics cookies: visit statistics (section 3.2) are produced without them.

Advertising cookies are activated only after you choose "Accept all" in the cookie notice. If you choose "Necessary only", they are not used, and our server passes nothing to Meta either. You may change or withdraw your choice at any time with the button below; when you withdraw consent, the advertising cookies are deleted. Withdrawing consent does not affect the lawfulness of processing carried out before withdrawal.

Change cookie choice

10. Changes to this policy

We may update this policy to reflect changes in our activities or in legislation. Material changes will be announced by email or by a notice on the Platform.