Privacy Policy – iMeter Reader

No account + no AI use: if you neither create an account NOR use any AI feature (cloud OCR, contract analysis, AI chat), your meters, meter readings, contracts, notes and settings never leave your device. Independently of your content data, the app transmits — even without an account — the one-time install ping (§ 4.10), anonymous usage statistics (§ 20, enabled by default, can be switched off), crash diagnostics (§ 19, enabled by default, can be switched off), the device-keyed record of your privacy choices (§ 21) and, while you allow notifications, the push registration (§ 18). Uninstalling the app removes all local data immediately; the device-keyed server records are deleted at the latest after the 18-month install-only retention period (§ 8.2). iMeter Reader (mobile app: iOS, Android, macOS, Windows) · Operator: Codexo (sole proprietorship of Ahmad Al Alloush), operator of the iMeter Reader mobile app · Last updated: 20 October 2026 · Version 2.19 · This version incorporates all in-place amendments of version 2.15 (18, 15 and 11 September 2026); the full amendment history is in § 23.

Die rechtlich verbindliche Fassung ist die deutsche Fassung. This is a courtesy translation. The legally binding version is the German document at /de/privacy.

This privacy policy describes which personal data is processed when you use the iMeter Reader mobile app, and on what legal basis. The controller is the app's operator (see § 1). The policy complies with the information obligations under Articles 13 and 14 GDPR, § 5 DDG (German Digital Services Act, formerly TMG) and § 25 TDDDG (German Telecommunications-Telemedia Data Protection Act, formerly TTDSG).

Product name note: The app is published in the App Stores under bundle ID imeterrecorder for historical reasons. The current brand and in-app name is iMeter Reader.

Controller and contact
Data Protection Officer (DPO)
Definitions
Categories of data we process
Purposes of processing and legal bases
Recipients and sub-processors
International data transfers (Chapter V GDPR)
Retention periods and erasure
Your rights as a data subject
Right to withdraw consent
Right to lodge a complaint with a supervisory authority
Obligation to provide data
Automated decision-making / profiling
Data security (Art. 32 GDPR)
Cookies and similar technologies (§ 25 TDDDG)
- Visiting our website
AI-powered features (OCR, contract analysis, chat)
Service push notifications and reminders
- 18a. Energy offers for your area (not yet available — coming soon)
- 18c. Verification of your German mobile number
Crash and diagnostic data (Sentry)
Anonymous usage statistics (device telemetry)
Device-keyed record of your privacy choices (pre-login)
Children under 16
Changes to this privacy policy
Annex A — List of sub-processors

1. Controller and contact

The controller within the meaning of Art. 4(7) GDPR is:

Codexo — sole proprietorship (Einzelunternehmen) of Ahmad Al Alloush

Dietmarstraße 4 · 87463 Dietmannsried · Germany

Email: support@imeterreader.app · Web: https://imeterreader.app

Tax status: small-business (Kleinunternehmer) under § 19 UStG — VAT not charged.

Note: "Codexo" is the business name under which Ahmad Al Alloush has registered a trade (Gewerbeanmeldung) and operates iMeter Reader. A sole proprietorship is not a separate legal entity: the controller is Ahmad Al Alloush personally, trading as Codexo. codexo.dev is Codexo's technical infrastructure domain (hosting, authentication, API).

For data-protection requests please email: support@imeterreader.app

2. Data Protection Officer (DPO)

The operator of iMeter Reader is not obliged to appoint a DPO under Art. 37 GDPR in conjunction with § 38(1) BDSG:

iMeter Reader is operated by a single person — well below the 20-person threshold of § 38(1) sentence 1 BDSG.
Core activities do not consist of processing operations that, by virtue of their nature, scope and/or purposes, require regular and systematic monitoring of data subjects on a large scale (Art. 37(1)(b) GDPR).
Core activities do not consist of large-scale processing of special categories of personal data (Art. 37(1)(c) GDPR).

Direct data-protection enquiries to the controller at support@imeterreader.app. We confirm receipt within 72 hours and respond within the statutory 30-day period (Art. 12(3) GDPR).

3. Definitions

We use the GDPR's terminology. "Personal data" is any information relating to an identified or identifiable person (Art. 4(1) GDPR), including:

IP addresses (CJEU case C-582/14 Breyer),
device identifiers such as a per-installation UUID,
energy- or water-consumption data when combined with a customer or contract identifier.

4. Categories of data we process

4.1 Account data

email address
first and last name
username
pseudonymous user ID (UUID, managed by Keycloak)

4.2 Address and contact (optional, stored in Keycloak)

street, house number
postal code, city, country
mobile phone (when entered in your profile; this number is not verified by SMS — the separate verification of a German mobile number that unlocks the AI features belongs to your installation, not to your account; see §§ 4.12 and 18c)

4.3 Energy and water data

energy supplier, contract number (customer number), tariff type
supply address (when you enter it) — street, house number and any further address detail you record here are stored only on your device and are not transmitted to our servers (Art. 6(1)(b) GDPR)
the postal code of the delivery point of an individual meter, where you enter it, and the locality we derive from it — unlike the supply address above, these two fields are part of the meter record: they are stored on your device and, when you are signed in and meter sync is active, they are also transmitted to and stored on our servers in Frankfurt, Germany (Art. 6(1)(b) GDPR). We derive the locality offline, on your device, from a postal-code reference dataset shipped inside the app (GeoNames postal-code data, © GeoNames, licensed under CC BY 4.0 — see our attributions page); no location request, no GPS and no IP-based geolocation is involved (see § 4.9). You can change or clear the postal code at any time; clearing it also clears the derived locality, on your device and on our servers.
market-location ID (Marktlokations-ID / MaLo) and metering-location ID (Messlokations-ID / MeLo), and your network and metering operator, where you record them — these are recorded and stored only on your device; they are not transmitted to our servers (Art. 6(1)(b) GDPR)
contract start / end / cancellation deadline
price structure (per-kWh, base fee, bonuses, price guarantees and, for two-direction (solar) meters, the feed-in remuneration per kWh you enter)
energy mix
meter tariff configuration you set for each meter: single-register meter, two-register day/night meter (German HT/NT day-and-night electricity meter), or two-direction (solar) meter that counts the energy you take from the grid and the energy you give to the grid
meter readings (value + date + register — day or night for two-register day/night meters; taken from the grid or given to the grid for two-direction (solar) meters — + optional note)
derived consumption series (daily, monthly, yearly) and, for two-direction (solar) meters, the energy given to the grid per day and the approximate feed-in earnings calculated from it — these derived figures are calculated and kept on your device only
free-text notes attached to contracts and readings
water supplier or metering service (e.g. a municipal utility, or a billing service such as Techem / ista) and water contract or customer number
cold-water and warm-water meter readings (value + date, in m³)
water price structure (€/m³, base fee)

4.4 Device and usage data

per-installation device UUID (per-install UUID, platform, OS/app version, country also used once for the install count — Art. 6(1)(f), see § 5)
platform (iOS / Android / macCatalyst / Windows)
operating-system version
app version
language and country setting
aggregated daily statistics: meters count, contracts count, readings count, app opens, session minutes
push registration: the Firebase Cloud Messaging registration token of this installation, platform, app language and app version — only while the operating-system notification permission is granted (see § 18)

4.5 Photo / document data (transient)

meter photos you capture (cropped, EXIF stripped)
contract documents you upload (a PDF or a photo): the app reads them on your device, and only the resulting text — not the file — is sent for AI analysis (§ 16.2)

→ These data are not persistently stored on our servers. They live only in memory for the duration of the AI processing and are discarded afterwards (see § 16).

4.6 Diagnostic and crash data

Error reports from four sources go to Sentry (§§ 6.5, 19): the mobile app, our servers, our website and our two internal staff web apps.

App: crash reports, reports of errors the app has caught and the app's own log lines of error level; breadcrumbs from the minutes before the error (app log lines, requests to our servers without query string, fixed screen names, route names and button presses — never text you type —, app lifecycle and system events); at most one report per app start about problems of the previous start; device info (manufacturer, model, operating system and version, rooted/jailbroken flag, language/locale, time zone, screen, memory and storage figures, battery state); app version and build.
Our servers: stack trace, error message and the log lines written before the error; HTTP method and request path; thread name, Java runtime version, server profile.
Website and staff web apps: error message, stack trace (script file URLs, line/column), page path including the language, the navigation and the site's own request paths before the error, Angular version. Your browser sends its User-Agent with the request; it is not evaluated.
In all cases without IP address. Email addresses, phone numbers, tokens, IP addresses and IBANs are replaced by "[redacted]" before sending; no user, account, installation or device identifier is attached to a report (for crashes caught by Sentry's own iOS component see § 19.1). Error messages and paths may contain internal random record identifiers (for example of a meter or a contract), and paths in our staff web apps can contain the internal identifier of an account — pseudonymous data.

4.7 AI chat content

the questions you type
up to 20 prior turns per session (max 1,000 characters per question)

4.8 Consents

per-purpose record of consents (granted/withdrawn, timestamp, policy version)

4.10 Install-count transmission data

On first launch after installation, the app transmits a single, one-time ping containing:

a randomly-generated per-installation UUID (created locally at install time, distinct from the sync UUID in § 4.4 once a user account exists, but the same UUID field is reused — see § 5 row on install counting)
platform (iOS / Android / macCatalyst / Windows)
operating-system version
app version
2-letter country code derived from the device locale setting (not from GPS, not from IP geolocation)

This ping fires once per installation, regardless of whether the user has enabled the "Anonymous usage statistics" toggle in § 20. No IP address, no account identifier, and no daily snapshot are included. The UUID is retained on-device in local storage for deduplication purposes; this on-device storage falls under § 25(2) No. 2 TDDDG (technically necessary for the purpose of the transmission, Art. 5(1)(b) GDPR). The legal basis for the transmission itself is Art. 6(1)(f) GDPR (legitimate interest — see § 5).

4.11 Device-keyed privacy-choice record (consent / objection state)

Before and without any account or login, the app transmits the current state of your per-option privacy settings to our backend over the device channel identified by the per-installation device UUID (§ 4.4, HTTP header X-Device-Id):

per-installation device UUID
per option — AI meter reading (OCR), AI contract analysis, AI chat, crash diagnostics (Sentry), anonymous usage statistics — the option identifier and its state: consent granted / withdrawn for the consent-based options (Art. 6(1)(a) GDPR); objection state objected / not objected for crash diagnostics and usage statistics (Art. 6(1)(f) / Art. 21 GDPR) — the latter are never recorded as consent
the version of the privacy policy shown on the device when the choice was made
timestamp of the last change
platform (iOS / Android / macCatalyst / Windows)

No name, email address, IP address or account identifier is part of this record. Details, purpose, retention and your rights: § 21.

4.12 Verification of your German mobile number (only if you use it)

These data are processed only if you verify a number (§ 18c), with or without an account, keyed to the per-installation device UUID:

Verification record — a keyed one-way hash of the verified number (not the number itself; a pseudonym, not anonymous data — see § 18c), a partly hidden form of it (for example +49 151 •••• 89), the status (verified, or moved to another installation), the source (your SMS, or marked by Codexo staff for app-store review — then without any number) and the times of the verification, of the last change and of a move
Pending code — a keyed hash of the number and of the 6-digit code (not the code itself), the partly hidden number, and the times the code was created and expires
Line-type result — the line type reported for the number by the line-type check (for example mobile, landline or VoIP), stored under the keyed hash of the number; no network operator
Processed-message record — a keyed hash of the message ID that Twilio gives your SMS; not your number and not the text of the SMS
AI usage counters per verified number — for each use of an AI feature: a pseudonymous ID derived from the keyed hash of the verified number, the kind of use and the time; no content
Grace-period record — for an installation that used one of these functions before the verification was introduced: the end of its grace period, and when the record was created and when the grace period ended

4.9 Data we do not process

We do not process:

advertising identifiers (no IDFA, no Google Advertising ID),
tracking pixels or third-party analytics SDKs (no Google Analytics, AppCenter, Mixpanel, Meta SDK, etc.; the Firebase SDK is included only for push delivery — Firebase Analytics is switched off in the app's configuration, see § 18),
biometric or health-related special-category data (Art. 9 GDPR),
location data (no GPS access; for historical reasons the iOS bundle still declares unused permission strings — these will be removed in the next release),
advertising or tracking cookies.

A postal code you type in yourself, and the locality we look up from it offline in a reference data set shipped with the app, are not location data in this sense: they are not measured from your device, and they describe a delivery point you told us about — not your whereabouts.

5. Purposes of processing and legal bases

The following table fulfils Art. 13(1)(c) and (d) GDPR.

Purpose	Data categories	Legal basis
Creating and maintaining your account, authentication	4.1, 4.2	Art. 6(1)(b) GDPR — performance of contract (iMeter Reader user agreement)
Preventing abuse of the registration, login and password-reset endpoints (rate limiting, brute-force protection)	IP address; a one-way hash of the submitted email address; timestamp	Art. 6(1)(f) GDPR — legitimate interest in protecting accounts and our infrastructure against credential-stuffing, brute-force and mass-registration abuse (documented balancing test on file). The hash is a pseudonym, not anonymised data. Our own rate-limit counters exist only in memory and are discarded within minutes; they are never written to a database and never logged. In addition, our identity service (§ 6.2) keeps a security event log of failed sign-in attempts (IP address, username, timestamp) for brute-force protection; its retention is stated in § 8.2.
Storing your energy and water contracts and meter readings on-device and (when signed in) syncing to our servers — the supply address, MaLo and MeLo fields (4.3) remain only on the device and are not transmitted; the per-meter postal code you enter and the locality derived from it are part of the meter record and are transmitted and stored with it	4.3	Art. 6(1)(b)
Providing historical consumption charts and analytics	4.3	Art. 6(1)(b)
Reminders for meter readings and contract deadlines (local notifications scheduled on your device)	4.3, 4.8	Art. 6(1)(b) + explicit opt-in (per-meter for meter-reading reminders, per-contract for contract-deadline notifications)
Operator service push notifications to installed apps (service, administrative and security announcements; never advertising) — see § 18	4.4 (push registration: token, platform, app language, app version, per-installation device UUID); for targeting: platform, app version, country and language setting, and whether the installation has been seen within a period we choose (at most 180 days)	Art. 6(1)(f) GDPR — legitimate interest in operating and securing the service and in reaching installed apps with service information (documented balancing test on file; see § 18); Art. 6(1)(c) for notices we are legally required to give (e.g. Art. 34 GDPR). Not consent-based and no in-app opt-in: what gates it is the operating-system notification permission (§ 25(1) TDDDG). You may object at any time (Art. 21): switch notifications for iMeter Reader off in your device settings — the app then deletes its registration from our servers on its next start — or email support@imeterreader.app.
Verification of your German mobile number: issuing the code, line-type check, receiving and matching the SMS you send, keeping the verified state of your installation, moving it to the installation on which the number was verified last, the grace period for earlier users, and making the AI features available only to verified installations — see § 18c	4.12 (verification of your German mobile number), mobile number	Art. 6(1)(b) GDPR — you ask for the verification so that you can use these functions, which we provide only to installations with a verified German mobile number. Art. 6(1)(f) GDPR — legitimate interest in preventing misuse and fraud (installations created in bulk that use up the AI features, which cost us money for every request) and in offering these functions only in the German market for which they are made; this covers the line-type check, the rule "one number, one installation", the limits, the processed-message record and the counting of AI use per verified number, so that removing and re-verifying a number does not reset the AI usage limits. The grace period is decided with dated records we already held about the use of these functions, only in your favour (Art. 6(4) GDPR). You may object (Art. 21); removing the verification in the app (§ 18c) has that effect.
Marking an installation as verified for app-store review (Codexo staff; without any number; for 14 days)	per-installation device UUID; admin access log	Art. 6(1)(f) GDPR — legitimate interest in having the app reviewed by the app stores, whose reviewers cannot send an SMS from a German mobile number. The action and its removal are logged (admin access log, 12 months).
AI meter reading (on-device first; cloud fallback to AKI.IO GmbH, Germany, when local OCR fails, § 6.3)	4.5 (transient), 4.3	Art. 6(1)(a) — consent
AI contract analysis	4.5 (transient), 4.3	Art. 6(1)(a) — consent
AI tariff-comparison chat	4.7	Art. 6(1)(a) — consent
Crash and error diagnostics (Sentry) — mobile app, our servers, our website and our staff web apps; see § 19	4.6	Art. 6(1)(f) GDPR — legitimate interest in stable, secure software and in finding and fixing errors quickly (documented balancing test on file; see § 19). Enabled by default — this is not consent-based processing; you may object at any time (Art. 21): in the app via Settings → Privacy → "Crash & diagnostic reports" — this also stops the error reports our servers send for the requests of that installation and, if you are signed in, of your account; on the website by sending Global Privacy Control or Do Not Track from your browser; otherwise by email to support@imeterreader.app.
Improving the provider directory from company details found in your contract documents (supplier's legal name, address, customer-service email, phone, website, energy type — generally no personal data) — see § 16.6	company details (generally no personal data; obvious personal details are discarded before storage); device UUID and account for the daily limit only	Art. 6(1)(f) GDPR — legitimate interest in a complete and correct provider directory for all users (documented balancing test on file; see § 16.6). Enabled by default — this is not consent-based processing; you may object at any time (Art. 21) via Settings → Privacy → "Help improve the provider directory".
Anonymous usage statistics (device heartbeat + daily snapshot)	4.4 (aggregated)	Art. 6(1)(f) GDPR — legitimate interest in quality assurance and product development (documented balancing test on file; see § 20). Enabled by default — this is not consent-based processing; you may object at any time (Art. 21) via Settings → Privacy → "Anonymous usage statistics".
Recording your per-option privacy choices server-side (device-keyed, also before/without any account)	4.11	Art. 6(1)(f) GDPR — legitimate interest in knowing your privacy choices on our servers as well and in documenting the device's current choice state (Art. 5(2), Art. 24); the choices themselves are enforced by the app (§ 21). The recorded choices themselves: AI features = consent state (Art. 6(1)(a), Art. 7 — granted/withdrawn); crash diagnostics and usage statistics = objection state (Art. 6(1)(f), Art. 21 — objected/not objected, never stored as consent). See § 21.
Counting unique app installations (product/operations metric)	Per-installation UUID, platform, OS version, app version, 2-letter country code derived from device locale (not GPS) — see § 4.10	Art. 6(1)(f) GDPR — legitimate interest in measuring adoption of a pre-release product. Balancing test: the UUID is randomly generated with no link to a natural person at creation; no IP, no contact data, minimal device metadata; suppressible/erasable on request. Distinction from § 20: this one-time install count is processed independently of the "Anonymous usage statistics" toggle in § 20: it fires once per installation even when usage statistics are disabled, transmits no daily snapshot and no IP, and is based on Art. 6(1)(f) — not on consent. The § 25 TDDDG analysis: the install-count transmission is non-essential analytics and does NOT rely on the § 25(2) No. 2 exemption; the legal basis is the Art. 6(1)(f) legitimate interest above. The separate on-device storage of the installation UUID for sync remains covered by § 25(2) No. 2 for its own purpose (Art. 5(1)(b)).
Admin/security access log (truncated IP)	Operator admin access to backend systems (truncated IP, timestamp, action)	Art. 6(1)(f) — legitimate interest in operational security and accountability. Retention: 12 months (GDPR Art. 17(3)(b)/(e) + Art. 32).
Operator-initiated service / administrative / security announcements to registered users	4.1 (email address)	Art. 6(1)(f) — legitimate interest in operating and securing the service; you may object at any time (Art. 21) via the unsubscribe link in every message.
Compliance with legal obligations (tax / commercial retention when paid features go live)	4.1 plus payment data	Art. 6(1)(c)
Handling your access / rectification / erasure requests	4.1	Art. 6(1)(c) in conjunction with Art. 15–22
Email correspondence via `support@imeterreader.app`	email content	Art. 6(1)(b) (pre-contract) or (1)(f) (responding to enquiries)

6. Recipients and sub-processors

We disclose data only to the recipients listed below, and only on the basis of written Data Processing Agreements (DPAs) under Art. 28 GDPR. The current list is in Annex A.

6.1 Hosting infrastructure

Hostinger International Ltd., Jonavos g. 60C, 44192 Kaunas, Lithuania (EU) → Server location: Frankfurt am Main, Germany (we explicitly use the German hosting region) → Data processed: all categories in 4.1–4.4, 4.7 and 4.12 — and, transiently and in memory only during AI processing, the 4.5 image/PDF data (see § 6.3) — except the supply-address, market-location ID (MaLo) and metering-location ID (MeLo) fields in 4.3, which remain only on your device and are not transmitted to Hostinger (see § 4.3) → International transfer: none — Hostinger is established in Lithuania (an EU member state); physical processing takes place in Germany. → DPA: Hostinger Data Processing Agreement (available in the Hostinger customer portal), signed.

6.2 Identity management

Self-hosted — Keycloak instance running on Hostinger servers in Frankfurt am Main, DE (auth.codexo.dev) → Not an external sub-processor; identity data remains within our own infrastructure on the same German server.

6.3 Artificial intelligence

AI-assisted analysis (hosting: AKI.IO GmbH) — To analyse contracts, bills and meter photos, and for the offers assistant chat, we use AI models that are hosted for us by AKI.IO GmbH, Marienburger Str. 1, 10405 Berlin, Germany. AKI.IO processes the submitted content on our behalf under a data processing agreement pursuant to Art. 28 GDPR. The models are hosted exclusively in Germany, in a data centre in Berlin; your content does not leave Germany and is never transferred to third countries. AKI.IO does not access, view, store or log your content (texts, images, results) and does not use it to train AI models. The content only passes automatically through the model in volatile memory for the duration of a single request and is discarded as soon as the result has been returned to us. Only the data you upload is processed (e.g. contract data, meter readings, meter number). The legal basis is Art. 6(1)(a) GDPR (your consent, given in the app for each AI feature; § 16). Results are generated automatically (AI-generated). Please check them before use.

→ Provider: AKI.IO GmbH, Marienburger Str. 1, 10405 Berlin, Germany (Amtsgericht Charlottenburg, HRB 281336 B) → Data processed: when AI features are enabled — your meter photo, the text of a contract or bill (read on your device from a PDF or a contract photo), or your chat conversation (up to 20 prior turns) → Models we use (hosted by AKI.IO): deepseek-v4.1-flash-552b (contract and bill text, meter photos) and qwen3.6-35b (offers assistant chat) → Transfer to a third country: none. → Sub-processor of AKI.IO: the only one is AIME GmbH, Berlin (bare-metal GPU servers in a data centre in Berlin, Germany; a shareholder of AKI.IO). AKI.IO may engage further sub-processors only with our approval and must report a personal data breach to us without undue delay. → Additional safeguards: no account identifier is transmitted, and the file name of anything you upload is replaced with a neutral one before the request leaves your device; the content is held in memory on our servers only for the duration of the request and is never stored there. A contract PDF or contract photo is read on your device (text layer or on-device text recognition); the IBAN — and your name, where your account profile provides it — is masked on your device, and only the resulting text is sent. Our server refuses contract images; the only image sent to AKI.IO is the meter photo, with EXIF data removed and reduced in size. Please note: the analysis deliberately reads identifiers printed on a contract (such as your customer number and meter number), and masking is limited to the IBAN and, where available, your name — this processing is therefore not fully pseudonymised. → Retention at AKI.IO: none — AKI.IO has no access to the content; it is processed only briefly in volatile memory, is not stored and not logged, and is not used to train AI models. → DPA: data processing agreement under Art. 28 GDPR with AKI.IO GmbH, concluded.

6.5 Crash and error data

Functional Software, Inc., d/b/a Sentry, 132 Hawthorne St, San Francisco, CA 94107, USA — with European entity Sentry GmbH, Schönhauser Allee 148, 10435 Berlin, Germany → Ingest endpoint: Frankfurt am Main, DE (*.ingest.de.sentry.io) → Data processed: error reports from the mobile app, our servers, our website and our staff web apps, all in one Sentry project of ours — stack traces, error messages, breadcrumbs or the log lines before the error, request and page paths, device info, app version (details in § 19). → Important: no IP address is transmitted to Sentry, and no user, account, installation or device identifier is attached to a report (paths in our staff web apps can contain the internal identifier of an account — pseudonymous data); the app sends no IP address (SendDefaultPii = false), and our Sentry project is set not to store IP addresses ("Prevent storing of IP addresses"). Email addresses, phone numbers, tokens, IP addresses and IBANs in error messages and log lines are replaced by "[redacted]" before sending. → Retention at Sentry: 90 days. → International transfer: primarily EU; intra-group transfers to the US parent cannot be excluded. Legal basis: SCCs and Data Privacy Framework. → DPA: Sentry Data Processing Addendum (https://sentry.io/legal/dpa/), signed.

6.6 Mobile platform provider (on-device OCR model on Android)

For on-device text recognition only: Google Ireland Ltd., Gordon House, Barrow Street, Dublin 4, Ireland — Google ML Kit Text Recognition → Text recognition runs entirely on your device; no image data is transmitted to Google. The model binary is delivered via Google Play Services. For the separate sign-in flow involving this provider, see § 6.11.

6.7 Mobile platform provider (on-device OCR on iOS / macOS)

For on-device text recognition only: Apple Inc., One Apple Park Way, Cupertino, CA 95014, USA — Vision framework → Processing is fully on-device; no image data is sent to Apple. For the separate sign-in flow involving this provider, see § 6.11.

6.8 Certificate authority

Internet Security Research Group / Let's Encrypt, USA — issues TLS certificates for *.codexo.dev. No personal data involved.

6.9 SMS and email delivery

Twilio Ireland Limited, 70 Sir John Rogerson's Quay, Dublin 2, D02 R296, Ireland (our contracting party), and Twilio Inc., 101 Spear Street, Suite 500, San Francisco, CA 94105, USA (data importer under Twilio's Data Protection Addendum) — verification of your German mobile number by an SMS that you send (§ 18c). We do not send any SMS. → Data processed: (1) line-type check — when you ask for a code, our server sends your mobile number to Twilio's Lookup service, which reports whether it is a mobile, landline or VoIP number; we keep only that line type (§ 4.12); (2) your SMS — Twilio operates our German mobile number, receives the SMS you send to it (your mobile number as the sender, our number, the text with the code, the time and a message ID) and forwards it to our server. → Location: our number and its messages are set up in Twilio's EU region (Ireland); access to them from the USA cannot be excluded (§ 7). The line-type check runs on the global Lookup service of Twilio Inc. in the USA: your number is sent there when you request a code (at most once in 30 days per number), also if you never complete the verification (§ 7). → Retention at Twilio: the message log of our number is kept for 7 days, with the text of the message and the sender number redacted; according to Twilio, the line-type check is kept only in Twilio's internal logs. → International transfer: USA — EU–US Data Privacy Framework (Implementing Decision (EU) 2023/1795; Twilio Inc. is certified) and the EU Standard Contractual Clauses (Implementing Decision (EU) 2021/914) included in Twilio's Data Protection Addendum. → DPA: Twilio Data Protection Addendum (https://www.twilio.com/en-us/legal/data-protection-addendum), part of Twilio's terms.

Twilio SendGrid (a Twilio business unit), 1801 California Street, Denver, CO 80202, USA — transactional and operator-initiated service/administrative email to registered users (e.g. account confirmations, security notifications, service/maintenance/security announcements). Each operator-initiated service message carries a one-click unsubscribe link and our Impressum. → Data processed: your email address, content of the email (e.g. confirmation link), send timestamp, and — for transactional email — optional open/click metadata per SendGrid account settings. Open/click tracking is disabled for operator-initiated service messages (no open/click metadata collected for those). → International transfer: USA — same legal basis as Twilio (SCCs + DPF). → Retention at SendGrid: activity logs up to 30 days for deliverability analysis, then deletion; content held only briefly in the send buffer. → DPA: SendGrid Data Processing Addendum (folded into the Twilio DPA), signed.

6.10 Public authorities

We disclose data to authorities only when legally required.

6.11 Sign-in providers (independent controllers)

If — and only if — you tap "Sign in with Google" or "Sign in with Apple", the app opens your device's system browser. The browser first contacts our own sign-in server at auth.codexo.dev, which we operate ourselves on our servers in Frankfurt, Germany (§ 4), and is forwarded from there without further interaction to the sign-in page of the provider you chose. On this route you never see and never fill in our own username-and-password form. No third-party identity broker is involved: apart from the provider you chose, the only identity service in the flow is our own. The browser session is opened, and the provider contacted, only after your tap. Our sign-in server receives from the provider only the identity token that provider issues and verifies it against the provider's published keys; it then issues the app a session token of our own. Neither our server nor the app ever receives your provider password.

Note on Apple "Hide My Email": if you sign in with Apple and choose "Hide My Email", Apple gives us a private-relay email address instead of your real one. If you later sign in again with a different method using your real email address, this can result in two separate accounts rather than one. To avoid this, choose "Share My Email" when signing in with Apple, or use the same email address consistently across sign-in methods. If you do end up with duplicate accounts, see § 9 for how to have them merged.

Google Ireland Ltd., Gordon House, Barrow Street, Dublin 4, Ireland → Data processed by Google: your Google account identity, your device and IP address, our application identifier and the time of sign-in. We receive back from Google: your Google user identifier (sub), your email address and — if present — your name. → Google acts here as an independent controller for its own sign-in processing, not as our processor. Google's privacy notice applies to that processing: https://policies.google.com/privacy → International transfer: Google Ireland is established in the EU; intra-group transfers to Google LLC (USA) cannot be excluded and are covered by Google's EU–US Data Privacy Framework certification and its Standard Contractual Clauses.

Apple Inc., One Apple Park Way, Cupertino, CA 95014, USA → Data processed by Apple: your Apple Account identity, your device and IP address, our application identifier and the time of sign-in. We receive back from Apple: your Apple user identifier (sub), an email address (your own, or an Apple private-relay address if you chose "Hide My Email") and — only on your very first authorisation — your name. → Apple acts here as an independent controller for its own sign-in processing, not as our processor. Apple's privacy notice applies: https://www.apple.com/legal/privacy/ → International transfer: USA, on the basis of Apple's EU–US Data Privacy Framework certification and the EU Standard Contractual Clauses.

Both providers learn that you sign in to iMeter Reader. If you do not want that, register with an email address and password instead — that route involves neither Google nor Apple.

6.12 Push delivery (Firebase Cloud Messaging)

Google Ireland Limited, Gordon House, Barrow Street, Dublin 4, Ireland (Firebase Cloud Messaging; Google LLC, USA, as intra-group sub-processor) → Data processed: a Firebase installation identifier created for this app installation, the push registration token of your installation, your platform (iOS / Android), and the content of each notification we send: service notifications (title, text, and the in-app screen or link it opens) → Trigger: the Firebase software component is initialised when the app starts and then contacts Google to create the installation identifier — this happens regardless of the notification permission; a registration token is obtained and sent to us only while you have granted the operating-system notification permission for iMeter Reader → International transfer: intra-group transfer to Google LLC (USA) possible; EU Standard Contractual Clauses and the EU–US Data Privacy Framework (Google LLC is certified) → DPA: Google Cloud / Firebase Data Processing and Security Terms. The token is stored on our own servers in Frankfurt am Main (§ 6.1) together with your platform, app language and app version. Firebase Analytics, Crashlytics and every other Firebase product are not used; the analytics collection is switched off in the app's configuration. See § 18.

On iOS, Firebase hands each notification to the Apple Push Notification service operated by Apple Inc., One Apple Park Way, Cupertino, CA 95014, USA: Apple receives the device's APNs token and the content of each notification in order to deliver it. Apple operates this service as the platform provider under the Apple Developer Program License Agreement; international transfer to the USA — Apple Inc. is certified under the EU–US Data Privacy Framework. On Android, delivery runs through Google Play services on your device (Google, above).

7. International data transfers (Chapter V GDPR)

International transfers occur to the recipients in § 6.5, § 6.9 and § 6.12 (Google LLC, USA, and — for the delivery of push notifications on iOS — Apple Inc., USA), and — only if you choose to sign in with Apple or Google (§ 6.11) — to Apple Inc. (USA) and, through possible intra-group transfer, to Google LLC (USA). Legal basis: EU Standard Contractual Clauses (Implementing Decision (EU) 2021/914) and, for those recipients that are certified under it, the EU–US Data Privacy Framework adequacy decision (Implementing Decision (EU) 2023/1795). AI processing is not among these transfers: the AI features are provided by AKI.IO GmbH, Berlin, which processes exclusively in data centres in Germany / the EU (§ 6.3). When you use an AI feature, no personal data is transferred to a third country, so no Standard Contractual Clauses and no Data Privacy Framework certification are needed for it.

The verification of your German mobile number is among these transfers (§§ 6.9, 18c): Twilio Inc. (USA) is the data importer for the SMS you send to our German mobile number and for the line-type check: for it, your number is sent to Twilio Inc. in the USA when you request a code. Twilio Inc. is certified under the Data Privacy Framework; the Standard Contractual Clauses in Twilio's Data Protection Addendum apply in addition.

Additional safeguards:

no user identifier and no file name transmitted; for contract text the IBAN and — where your account profile provides it — your name are masked on your device (names or addresses inside the contract text itself may still be read by the model),
TLS 1.3 + certificate pinning in the mobile app,
storage limits at the recipient (7 days for the message log of our Twilio mobile number, 30 days SendGrid, 90 days Sentry),
prior-notification obligation regarding sub-processors (SCC Clause 9 / Art. 28(2) GDPR): Sentry and Twilio/SendGrid are each contractually required to inform us in advance of any addition or replacement of their own downstream sub-processors. We may object — and where appropriate terminate the contract — before new sub-processors gain access to your data. The only sub-processor of AKI.IO (AI processing, no third-country transfer) is AIME GmbH, Berlin; AKI.IO may engage new sub-processors only with our approval.

A copy of the relevant SCCs is available on request at support@imeterreader.app.

8. Retention periods and erasure

We retain personal data only as long as needed for the purposes in § 5, or until you withdraw consent / object to legitimate-interest processing.

8.1 Offline-first — the default is no data transmission

iMeter Reader is an offline-first app: as long as you do NOT sign in to an account, no contracts, meter readings, notes or other content data are transmitted to our servers. Your content data lives only on your device, in the app's own private storage. (For the narrow technical transmissions that occur even without an account, see the first bullet below and § 4.10 / §§ 18–21.)

Concretely:

Verification of your German mobile number: if you verify your German mobile number, the verification data described in § 18c (§ 4.12) are sent to and stored on our servers, with or without an account.
With account (cloud sync): if you create an account and use sync, contracts, meter readings and settings are replicated to our servers (see table below). "Delete account" wipes those server-side copies.
With AI use: if you used an AI feature, the corresponding image / PDF / chat message passes through our servers in Frankfurt in memory only and is forwarded to AKI.IO GmbH in Germany (§ 6.3); we retain no copy after processing. AKI.IO processes the content only briefly in volatile memory and neither stores nor logs it — there is no retention period at AKI.IO. The extracted structured data is saved only on your device.
Sentry diagnostics: error reports — from the app (crash diagnostics are enabled by default — § 19), from our servers, our website or our staff web apps — stay at Sentry for up to 90 days, then are deleted.

8.2 Retention per data category

Data category	Retention
Account & master data (4.1, 4.2)	Until account deletion + 30-day grace period
Energy contracts and meter readings (4.3)	Locally on your device: while the app is installed. On our servers: only when signed-in and cloud sync is on; on account deletion, cascade delete within the 30-day grace period. You can remove individual records from the app at any time.
Meter photos / contract texts (4.5)	Not persistently stored on our servers. Held in memory on our servers in Frankfurt for the duration of the AI request (seconds to minutes), then discarded. Forwarded to AKI.IO GmbH in Germany (§ 6.3), which processes it only briefly in volatile memory and does not store or log it (no retention at AKI.IO).
Install-count record (§ 4.10) — device never linked to a user account	Maximum 18 months from first install, then deleted — regardless of any telemetry or diagnostics setting.
Device-keyed privacy-choice record (§ 4.11 / § 21) — device never linked to a user account	Maximum 18 months from the device's first contact, then deleted together with the install record — regardless of the stored states. On account erasure (Art. 17), the device's privacy-choice records are deleted immediately and the device reverts to install-only status.
Device telemetry — raw daily (4.4 snapshots)	90 days
Push registration (token, platform, app language, app version — § 18)	Until you switch notifications for iMeter Reader off in your device settings, delete your account or uninstall the app (the app deletes the registration on its next start after the first two; after an uninstall the token becomes invalid and is removed the next time a delivery fails). A registration is deleted automatically once the installation has not been reported active for 270 days — by the anonymous usage statistics (§ 20).
Verification of your German mobile number (§ 18c) — keyed hash and partly hidden number, status, source, times	Deleted when you tap "Remove from this device", when you delete your account (installations on which only your account is signed in), and at the latest when the installation has not been active for 18 months or its device record no longer exists. When the same number is verified on another installation, the hash and the partly hidden number are deleted from the earlier installation at once; only the status "moved" and its time remain there.
Pending verification code (keyed hashes, partly hidden number, times — § 18c)	Valid for 10 minutes; deleted 24 hours after it expired, and at once when the number is verified, when you request a new code or when you remove the verification.
Line-type result of a number (keyed hash, line type — § 18c)	30 days after the check.
Processed-message record (keyed hash of the message ID of your SMS — § 18c)	7 days.
AI usage counters per verified number (pseudonymous ID derived from the keyed hash of the number, kind of use, time — § 18c)	Only for their counting window, at most 31 days; deleted earlier on an erasure request made with your phone number (§ 18c).
Grace-period record (§ 18c)	30 days after the end of the grace period; deleted earlier with the installation's other verification data.
Message log of our German mobile number at Twilio (text and sender number redacted — § 6.9)	7 days (at Twilio).
Admin push-broadcast log (operator-initiated service push — acting admin, timestamp, filter descriptor, content class, title and text, target screen or link, recipient / delivered / failed counts, truncated IP; no device identifiers and no tokens)	12 months
Device telemetry — monthly aggregates	24 months
Admin/security access log (truncated IP)	12 months (GDPR Art. 17(3)(b)/(e) + Art. 32 — accountability/security evidence)
Email suppression record (unsubscribe from operator-initiated service email)	Retained until account deletion
Admin broadcast log (operator-initiated service email — acting admin, timestamp, filter descriptor, content class, subject, recipient count, truncated IP; no recipient addresses)	12 months
AI chat content (4.7)	Local: until you close the app. Server: not persistent.
Sentry diagnostics (4.6 — app, our servers, website, staff web apps; § 19)	90 days
Provider-directory suggestions (company details only — § 16.6)	Rejected: 12 months; unconfirmed suggestions: 24 months after the last report; confirmed suggestions become directory entries
Provider-directory feedback vote (one-way hash of device UUID + entry — § 16.6)	30 days
Provider-directory suggestion sighting (one-way hash of device UUID + suggestion — § 16.6)	30 days
Consent log (4.8)	Business relationship + 3 years (to prove consent under Art. 7(1))
Tax / commercial records (when paid features go live)	10 years (§§ 257 HGB, 147 AO)
Rate-limit counters for registration / login / password reset (IP, hashed email)	In memory only; discarded automatically within a short window (minutes). Never persisted, never logged.
Identity-service security event log (failed sign-ins: IP address, username, timestamp)	Kept only as long as needed for brute-force protection and security review; we are in the process of setting an automatic 30-day expiry. Ask `support@imeterreader.app` for the current setting.
Account registered but never used: email address never confirmed, no sign-in with Google or Apple, and never signed in to the app	90 days from registration, then automatic deletion (one reminder at day 60). Accounts that have been used are never deleted by this rule.

Local data is held in the app's own private storage on your device until you uninstall the app or use the "Delete account" function. That function removes the energy and water data (§ 4.3) held on the device once our servers have confirmed the deletion request; settings that configure the app on this device — language and display preferences — deliberately remain, and reinstalling the app removes anything left.

9. Your rights as a data subject

Right	Scope	How to exercise
Access (Art. 15)	Receive a full copy of data we hold about you	Email `support@imeterreader.app`; a copy is provided within 30 days.
Rectification (Art. 16)	Correct inaccurate or incomplete data	Profile screen in the app, or written request.
Erasure / right to be forgotten (Art. 17)	We delete your data unless there is a legal retention obligation	In-app: open the menu → tap your profile → Profile → Delete Account. Full cascade within the 30-day grace period. See the dedicated account-deletion page for full details.
Restriction (Art. 18)	Suspend processing	Email `support@imeterreader.app`.
Portability (Art. 20)	Receive your data in a structured, commonly used, machine-readable format	On request to `support@imeterreader.app`, data is provided in a structured, commonly used, machine-readable format.
Objection (Art. 21)	Object to processing based on legitimate interest (install count — § 4.10 / § 5; operator-initiated service email — § 5 / § 6.9; operator service push notifications — § 18; crash diagnostics — § 19; anonymous usage statistics — § 20; device-keyed privacy-choice record — § 21). You may object to the install-count processing under Art. 21 GDPR; we will then suppress any further processing of that record and delete it ahead of the 18-month retention period. For crash diagnostics and anonymous usage statistics, the toggles in Settings → Privacy are the easy objection channel: switching an option off is treated as an objection and is recorded server-side via the device-keyed privacy-choice record (§ 21); it takes effect immediately for usage statistics and from the next start of the app for crash diagnostics (§ 19). For error reports from our website (§ 19.3), the Global Privacy Control or Do Not Track signal of your browser is the easy objection channel: while your browser sends either signal, no error report is sent at all. If you switch off "Crash & diagnostic reports" in the app, our servers also stop sending error reports for every request from that installation and — if you are signed in — for every request of your account from any device, at the latest five minutes after the app has transmitted your choice to our servers. For the staff web apps and for server tasks that serve no particular request, object by email; we handle such objections case by case and delete matching reports. For operator-initiated service email, the one-click unsubscribe link in every message is the easy objection channel; it adds you to our suppression store and stops any further such messages. For service push notifications, switching notifications for iMeter Reader off in your device settings is the easy objection channel: the app then deletes its push registration from our servers on its next start, and no further notification can reach the device. For the verification of your German mobile number (line-type check and misuse protection — § 18c), removing the verification in the app is the easy objection channel.	Email support@imeterreader.app, use the toggles in Settings → Privacy, use the unsubscribe link for service email, switch notifications off in your device settings for push, or turn on Global Privacy Control or Do Not Track in your browser for website error reports.
No automated decision-making (Art. 22)	We do not take automated decisions with legal or similarly significant effect	Questions: email `support@imeterreader.app`.

Handling your request is free of charge. We may require a one-time email confirmation to verify your identity.

Duplicate accounts: if choosing "Hide My Email" with Apple sign-in (§ 6.11) has left you with two separate accounts, email support@imeterreader.app and we can merge them on request. This does not change the 30-day response window above.

10. Right to withdraw consent

Where processing is based on consent (AI meter reading, AI contract analysis, AI chat), you may withdraw it at any time with effect for the future. Withdrawal is as easy as giving consent:

In-app: Settings → Privacy → per-purpose toggles (AI meter reading, AI contract analysis, AI chat).
Email to support@imeterreader.app.

The lawfulness of processing carried out before the withdrawal remains unaffected.

Crash diagnostics (Sentry, § 19) and anonymous usage statistics (§ 20) are not consent-based: they run by default on the basis of legitimate interest (Art. 6(1)(f) GDPR). The corresponding toggles in Settings → Privacy exercise your right to object (Art. 21 GDPR) rather than withdrawing a consent; your objection is recorded via the device-keyed privacy-choice record (§ 21).

11. Right to lodge a complaint with a supervisory authority

You have the right to lodge a complaint with a data-protection supervisory authority. The operator is based in Bavaria, so the competent authority is:

Bayerisches Landesamt für Datenschutzaufsicht (BayLDA) · Promenade 18 · 91522 Ansbach, Germany · Phone: +49 (0) 981 180093-0 · Email: poststelle@lda.bayern.de · Web: https://www.lda.bayern.de

A list of German DPAs: https://www.bfdi.bund.de/EN/Home/home_node.html

12. Obligation to provide data

To create an account you must provide an email address and set a password — or sign in with Google or Apple, in which case the email address comes from that provider. Your name is optional; if you do not provide one, the app addresses you by your email address instead. Without an account, cloud sync is not available — but all core features (meter reading capture, contract management, reminders) work fully offline; apart from the transmissions described in §§ 4.4, 4.10 and 18–21 (install count, push registration while you allow notifications, crash diagnostics, usage statistics, device-keyed privacy-choice record — each open to objection or switch-off), no data is sent to our servers.

Other data is optional. Not providing it simply means the related feature is unavailable. To use the AI features (meter-photo reading, contract analysis, AI chat), you must verify a German mobile number by sending us an SMS from it (§ 18c); without the verification these functions are not available once the grace period described there has ended. All other functions of the app remain available without it.

13. Automated decision-making / profiling

We make no decisions based solely on automated processing that produce legal or similarly significant effects (Art. 22 GDPR). AI features are assistive (OCR and structured-extraction suggestions); you always review and confirm.

When you verify your mobile number (§ 18c), numbers that are not German mobile numbers — for example landline or VoIP numbers — are refused automatically. The only effect is that the verification cannot be completed with that number; this is not a decision with legal or similarly significant effect. If you think your number was refused wrongly, email support@imeterreader.app.

14. Data security (Art. 32 GDPR)

We use up-to-date security standards:

Transport encryption: TLS 1.3, HSTS, OCSP stapling. The mobile apps additionally enforce Subject Public Key Info pinning (SPKI pinning) for auth.codexo.dev and imeterreader.codexo.dev — even a compromised CA cannot man-in-the-middle. Sign-in — with email and password as well as with Google or Apple — uses the OIDC authorization-code flow with PKCE in your device's system browser and is brokered by our own identity service as described in § 6.2 and § 6.11. Our public website is served at imeterreader.app.
Secure token storage: auth tokens live exclusively in iOS Keychain / Android Keystore, never in Preferences / NSUserDefaults.
RBAC: backend endpoints are protected by JWT validation and resource-owner checks; admin endpoints additionally require the Keycloak role imeterreader_admin.
Input validation & hardening: strict JSON schemas; MIME allow-list + magic-byte check for uploads; 7 MB cap; correlation-ID sanitisation; CORS fail-closed in production.
Audit log: operator/admin access to backend systems is logged with the acting admin identity, truncated IP, action and timestamp (12-month retention); see § 5.
At-rest encryption: database + backup encryption at Hostinger; local SQLite protected by OS data-protection class (iOS) / File-Based Encryption (Android). SQLCipher on-device is on the roadmap.
Backups: daily encrypted, stored on a separate storage box.
Patch management: all container images version-pinned; CVE monitoring via Dependabot.
Incident response: documented 72-hour breach-notification procedure (Art. 33).

A detailed TOMs catalogue is available to business partners on request (support@imeterreader.app).

15. Cookies and similar technologies (§ 25 TDDDG)

The iMeter Reader mobile app uses no advertising or tracking cookies.

We only use data types that are strictly necessary for the app to function and are exempt under § 25(2) TDDDG:

your sign-in session in OS-secure storage (iOS Keychain / Android Keystore): access, refresh and ID token (Keycloak), their expiry times, your user ID, your username, your display name and your email address,
the per-installation device UUID for sync,
language and UI preferences,
a strictly-necessary session/state cookie set by our identity service (auth.codexo.dev) during sign-in — with email and password as well as with Google or Apple: it binds the OIDC state and PKCE parameters to your browser session and, once you are signed in, carries the identity-service login session. Persistence differs by platform: on iOS, the browser session is ephemeral (ASWebAuthenticationSession) — the cookie is discarded as soon as the sign-in flow completes and nothing persists afterwards. On Android, the flow opens in a Chrome Custom Tab, which shares your device browser's regular cookie jar, so the cookie persists there until the identity-service login session expires; we are in the process of confirming and documenting that session's exact lifetime. Ask support@imeterreader.app for the current setting.

Consent-required items (AI features) are gated by an explicit in-app dialog before activation; see § 16. Crash diagnostics (Sentry) and anonymous usage statistics are enabled by default on the basis of legitimate interest; you can object to them / switch them off at any time in Settings → Privacy (Art. 21 GDPR; see §§ 19, 20).

The associated back-office (imeterreader-admin.codexo.dev) is used only by the operator and is not consumer-facing.

Visiting our website

When you open our website (imeterreader.app), your browser transmits technical connection data to our server in Frankfurt (Hostinger): your IP address, browser user-agent and preferred language (Accept-Language). We use these only to deliver the site, to show it in your language, and — when you open our download link /get — to send you to the correct app store for your device (Apple App Store on iOS, Google Play on Android). This routing reads your user-agent in the moment of the request and does not store or log it; the redirect sets Cache-Control: no-store. We make no outbound call — your own browser follows the redirect to Apple or Google, exactly as if you had tapped a store badge.

Legal basis: our legitimate interest in providing and correctly routing our website (Art. 6(1)(f) GDPR). We do not use cookies or similar identifiers for this and do not build any profile from it. You can object under Art. 21 GDPR at support@imeterreader.app.

Error reports (Sentry). If a JavaScript error occurs in your browser while you use our website, the site sends an error report to Sentry (§§ 6.5, 19.3): the error message (email addresses, phone numbers, tokens, IP addresses and IBANs replaced by "[redacted]"), the stack trace (script file URLs, line and column), the path of the page including the language (without query string or fragment), your navigation and the site's own request paths before the error, and the Angular version. The script does not read your browser's User-Agent or referrer; your browser transmits its User-Agent with every request, including this one, but Sentry is not asked to evaluate it. No cookies are set and nothing is stored on your device; no user identifier is sent and Sentry stores no IP address; there is no performance measurement and no session replay. If your browser sends Global Privacy Control or Do Not Track, no error report is sent at all. Legal basis: Art. 6(1)(f) GDPR — our legitimate interest in a stable, secure website and in fixing errors quickly. You may object at any time via Global Privacy Control or Do Not Track, or by email to support@imeterreader.app. Sentry deletes the reports after 90 days.

16. AI-powered features (OCR, contract analysis, chat)

iMeter Reader offers three optional, individually enabled AI features:

16.1 AI meter reading (OCR)

Local-first: by default, OCR runs on-device (Apple Vision on iOS; Google ML Kit on Android). No image is sent to our servers.
Cloud fallback (optional, consent-required): if local OCR fails, you may switch to cloud OCR. The image (~ 960 × 300 px, JPEG q90, EXIF stripped) is sent to our backend and from there to AKI.IO GmbH, Berlin (§ 6.3; processing exclusively in data centres in Germany / the EU). Response: the extracted numeric reading.
You are never required to use it. Entering a reading by hand is always available, needs no consent, and sends nothing anywhere.
Limit: maximum 3 cloud OCR calls per week.

16.2 AI contract analysis

You may upload a contract PDF or multi-page photo PDF. Where the PDF contains extractable text, the app first checks on your device whether it looks like an energy contract of the type you selected; if it clearly is not, the upload is refused locally and nothing is sent. Otherwise a PDF or a contract photo is read on your device (text layer or on-device text recognition); the IBAN — and your name, where your account profile provides it — is masked on your device, and only the resulting text is sent through our backend (in memory only) to AKI.IO GmbH, Berlin (§ 6.3; processing exclusively in data centres in Germany / the EU). No contract image is sent: our server refuses contract images.
Response: a structured contract record that you review and optionally correct before saving.
Note: contract documents often contain sensitive data (name, address, customer number, IBAN/SEPA). The IBAN — and your name, where your account profile provides it — is masked on your device; other data such as address and customer number is processed. We recommend redacting fields you do not want AI-processed before uploading.
Limit: 2 electricity and 2 gas contracts per month.
Provider directory (§ 16.6): after the analysis the app may report the company contact details found in the document (supplier's legal name, address, customer-service email, phone, website) to our provider directory. Nothing about you or your contract is included. You can object at any time (Settings → Privacy → "Help improve the provider directory").

16.3 AI chat (tariff assistant)

Ask questions about energy tariffs, provider differences, cancellation periods, etc.
Your input and the last 20 turns of conversation are sent to our backend and from there to AKI.IO GmbH, Berlin (§ 6.3). The model does not run on our own servers; it is hosted for us by AKI.IO exclusively in a data centre in Berlin, Germany — your text stays in Germany.
Please do not enter sensitive personal data of third parties in the chat.
Per-question input limit: 1,000 characters — deliberately kept low so that no large volume of personal data is inadvertently transmitted to our servers (data minimisation, Art. 5(1)(c) GDPR).
Daily limit: 20 requests per day.

16.4 Consent-based

All three AI features ship disabled. They activate only after your explicit, per-feature consent. You can review and revoke at any time in Settings → Privacy. In addition, once the verification of German mobile numbers has been introduced, the AI features can be used only on an installation with a verified German mobile number (§ 18c). The verification does not replace your consent, and you can withdraw your consent at any time without it.

16.5 No training of AI models

We do not — and will not — use your meter images, contract documents, AI-chat messages or any other content you submit to train, fine-tune or improve any AI model. To be absolutely clear, and we reiterate: we do not train any artificial intelligence on user data. Our AI features are provided by AKI.IO GmbH in Berlin (§ 6.3), which has confirmed in writing that it does not use content submitted to it to train AI models either. Your uploaded images, PDFs and chat messages are processed in memory only, for the duration of the request, and are discarded immediately afterwards; we do not store them on our servers. AKI.IO processes content only briefly in volatile memory and neither stores nor logs it; there is no retention period at AKI.IO. Please be aware that this means your content is sent to a third-party AI provider (AKI.IO GmbH, Berlin; processing exclusively in data centres in Germany / the EU, without transfer to a third country) — if you would rather it were not, do not enable the AI features: every one of them is optional, requires your consent, and has a manual alternative.

There is currently no opt-in that would allow your content to be used for model training. If we ever introduce such an option in a future version, it would require a separate, explicit, freely-given consent under Art. 6(1)(a) GDPR — silence, continued use of the app, or pre-ticked boxes would never count as consent (Art. 4(11), Art. 7 GDPR; EDPB Guidelines 05/2020 on consent).

16.6 Improving the provider directory from your contract documents

The app contains a directory of energy suppliers (name, address, customer-service email, cancellation channel) that helps you contact or cancel your provider. To keep this directory complete, the app may — after a successful contract analysis (§ 16.2) — send us the company details that the analysis found in your document: the supplier's legal name, its street address, its customer-service email address, telephone number and website, together with the energy type (electricity or gas).

What is never sent for this purpose: your name, your address, your customer number, your meter number, prices, consumption, the document itself or any identifier of your contract or account. The request carries the per-installation device UUID (§ 4.4) and — because contract analysis requires you to be signed in — your login token; we use both solely to limit the number of reports (20 per day per installation and per account). Neither the device UUID nor your account is stored with the suggestion.
What we store: if the company is already in the directory, nothing is stored. Otherwise the company details are stored as a suggestion together with a counter of how many installations reported them; to count each installation only once, we keep for 30 days a one-way hash of your device UUID and the suggestion. A suggestion becomes a visible directory entry only after we have checked it by hand against the supplier's official website. Company data of this kind is generally not personal data. Should the analysis nevertheless pick up details of a person (for example the details of a sole trader or, by mistake, your own), we discard obvious personal details before storing anything — addresses at free e-mail providers and German mobile numbers are dropped, and nothing is stored unless the data clearly describes a company — and every suggestion is checked by hand before it becomes visible.
Legal basis: Art. 6(1)(f) GDPR — our legitimate interest in a complete and correct provider directory for all users (documented balancing test on file). Enabled by default — this is not consent-based processing; you may object at any time (Art. 21) via Settings → Privacy → "Help improve the provider directory". After an objection the app sends nothing for this purpose, and our servers refuse such reports from an installation that has objected.
Feedback on a directory entry: when you use the cancellation assistant you may tell us whether the channel worked or whether the data was wrong. We store only a counter per entry and, for 30 days, a one-way hash of your device UUID and the entry, so that each installation counts once.
Retention: rejected suggestions are deleted after 12 months; suggestions not confirmed within 24 months of the last report are deleted; the hashes for feedback votes and suggestion sightings after 30 days. Recipients: our servers at Hostinger in Frankfurt am Main (§ 6.1) only; no third-country transfer.

18. Service push notifications and reminders

Reminders stay local. All reminders (meter readings, contract end dates, cancellation deadlines) are local notifications scheduled by the app on your device. No reminder content leaves your device.

Service push notifications (from the first app version released after 7 September 2026 / policy version 2.14). In addition, we can send service notifications to installed apps — for example a notice that an app update is required, a security notice, a planned maintenance window, or a notice we are legally required to give. Service notifications never contain advertising: on this service channel the advertising message class is switched off at server level, and any message declared as advertising is rejected. Advertising push notifications are not sent.

What is processed. When you have granted the operating-system notification permission for iMeter Reader, the app obtains a registration token from Firebase Cloud Messaging (Google, § 6.12) and sends it to our servers together with your platform, your app language and your app version, keyed to the per-installation device UUID (§ 4.4). The token is a random identifier issued for this installation; it is not linked to your name or email address, and it is not used for analytics. Firebase Analytics is switched off in the app's configuration. The Firebase software component itself is initialised when the app starts and creates an installation identifier with Google regardless of the permission (§ 6.12); the registration token, however, is obtained and sent to us only with the permission. The app sends or renews this registration at most about once a month, and whenever the token, your app language or your app version changes; our server then only updates the stored registration. Sending or renewing it does not record that the installation was seen or active — that information comes only from the anonymous usage statistics (§ 20), so it is not collected if you have objected to them.
How we choose recipients. For a notification we may select installations by platform, app version, country and language setting (so that you receive the message in your app language, with English as fallback), and by whether the installation has been seen within a period we choose (at most the last 180 days, as reported by the anonymous usage statistics, § 20), or — for a service message that concerns your account — by account. No behavioural profile is created.
Delivery. The notification is handed to Google (Firebase Cloud Messaging), which delivers it via the Apple Push Notification service (Apple Inc., USA) on iOS and via Google Play services on Android. Google — and on iOS also Apple — therefore sees the token and the content of each notification; see § 6.12 and § 7 for the recipients and transfer safeguards.
Legal basis. Our legitimate interest in operating and securing the service and in reaching installed apps with service information (Art. 6(1)(f) GDPR; balancing test on file); Art. 6(1)(c) for notices we are legally required to give. Service push notifications are not consent-based and there is no in-app opt-in: the control is the operating-system notification permission (§ 25(1) TDDDG).
Your objection (Art. 21). Switch notifications for iMeter Reader off in your device settings. The app then deletes its registration from our servers on its next start, and no further notification can reach the device. You can also object by email to support@imeterreader.app. Deleting your account or uninstalling the app removes the registration as well.
Retention. The registration is kept while notifications are enabled; it is deleted automatically once the installation has not been reported active for 270 days — by the anonymous usage statistics (§ 20; see also § 8.2). If you have objected to the usage statistics, this can happen even while you still use the app. For each notification we keep an operator log of the acting admin, the time, the selection criteria, the content, and the delivery counts for 12 months — without any device identifiers or tokens.
What we do not do. No push token is transmitted for reminders; no advertising push; no per-user tracking of opens or taps.

Android requires POST_NOTIFICATIONS (for reminders and service notifications), SCHEDULE_EXACT_ALARM and RECEIVE_BOOT_COMPLETED (the last so that reminders survive a device restart).

18a. Energy offers for your area

Energy offers for your area: this service is not yet available in the app (coming soon). When it starts, this policy will describe it before you can switch it on.

18c. Verification of your German mobile number

The AI features — meter-photo reading, contract analysis and the AI chat (§ 16) — are made for customers in Germany, and they can be misused: every AI request costs us money. From the date on which we introduce the verification, these functions are therefore available only on an installation that has verified a German mobile number (+49). The verification belongs to the installation of the app on your device, not to your account: you do not need an account, and after a reinstallation you verify again. If you do not have a German mobile number, these functions are not available to you; all other functions of the app remain available.

How it works.

You enter your German mobile number in the app. Our server checks that it is a German mobile number (+49 15, 16 or 17) and sends it to Twilio's line-type check in the USA (§§ 6.9, 7) to learn whether it is a mobile number — also if you then never send the SMS; landline, VoIP and other numbers are refused (§ 6.9). The result is kept for 30 days under a keyed hash of the number, so that the same number is not checked again during that time.
Our server creates a 6-digit code that is valid for 10 minutes, and the app prepares an SMS to our German mobile number with the text "IMR" and the code. You send it yourself from your phone — from the SIM card of the number you entered. It is an ordinary SMS; your mobile tariff decides what it costs you. We never send you an SMS.
Twilio receives your SMS and forwards it to our server. If the sender number and the code match, your installation is verified, and the app shows the number partly hidden (for example +49 151 •••• 89). A new code request replaces the previous code.

What we store (on our servers in Frankfurt; § 4.12): a keyed one-way hash of your number — not the number itself — and its partly hidden form, the status, the source and the times; while a code is pending, a keyed hash of the code; the line-type result under the hash of the number; and a keyed hash of the message ID of your SMS, so that the same SMS is not processed twice. These hashes are pseudonyms, not anonymous data: with our secret key, a hash can be recomputed from a number, so we keep the key secret. So that removing and verifying a number again does not reset the usage limits of the AI features (§ 16), we also count AI use per verified number, under a pseudonymous ID derived from the keyed hash of the number; these counts are kept only for their counting window (at most 31 days). We do not store the text of your SMS or your number in readable form, and our server logs contain neither your number, nor the code, nor the text. To prevent misuse, our server also counts code requests per installation and per shortened network address, and incoming SMS per sender (by the keyed hash), in its working memory only and for at most one day.

One number, one installation. A number can be verified on only one installation at a time. If the same number is verified on another installation, the verification moves there: the earlier installation loses its verified status, and the hash and the partly hidden number are deleted there; only the status "moved" and its time remain. If someone verified a number that is not theirs, the holder of the number can take it over in this way at any time.

What the verification unlocks. On a verified installation you can use the AI features for which you gave your consent (§ 16). Without a verification, and after the grace period, these functions are blocked. Switching a function off, withdrawing a consent and deleting data are never blocked.

Grace period for earlier users. An installation that, before the introduction date, had given its consent to an AI feature, or was linked to an account that had used a cloud AI feature, can keep using the AI features without a verification for 30 days from the introduction date; the app shows when the grace period ends. To decide on the grace period, our server uses records that we already hold for other purposes and that are dated before the introduction: the records of your AI consents and the AI usage counts of a linked account. We use them only for this check, only in your favour and without passing them on; this further use is compatible with their original purposes (Art. 6(4) GDPR). For the installation we store only the end of the grace period. The grace period ends early when you verify a number.

Removing the verification. You can remove the verification from your installation in the app at any time ("Remove from this device"). This deletes the verification, a pending code and the grace-period record of the installation at once; afterwards the functions listed above are blocked again until you verify a number.

App-store review. The reviewers of the app stores cannot send an SMS from a German mobile number. Codexo staff can therefore mark a single installation as verified, without any number, for 14 days; the marking then expires and is deleted within about an hour. The marking and its removal are logged in our admin access log (§ 5).

Legal basis. Art. 6(1)(b) GDPR — you ask for the verification so that you can use functions that we provide only to installations with a verified German mobile number. Art. 6(1)(f) GDPR — our legitimate interest in preventing misuse and fraud (installations created in bulk that use up the AI features) and in offering these functions only in the German market for which they are made; this covers the line-type check, the rule "one number, one installation", the counts in working memory, the processed-message record and the counting of AI use per verified number. The grace period is decided with records we already held, only in your favour (Art. 6(4) GDPR). Marking an installation for app-store review: Art. 6(1)(f) GDPR. You may object to the processing based on Art. 6(1)(f) (Art. 21 GDPR, § 9); removing the verification has that effect.

Retention (see also § 8.2): verification — deleted when you remove it, when you delete your account (installations on which only your account is signed in), and at the latest when the installation has not been active for 18 months or its device record no longer exists; when the number moves to another installation, the hash and the partly hidden number are deleted at once; pending code — valid for 10 minutes, deleted 24 hours after it expired; line-type result — 30 days; processed-message record — 7 days; AI usage counters per verified number — only for their counting window, at most 31 days; grace-period record — 30 days after the end of the grace period; message log of our number at Twilio — 7 days, with text and sender number redacted.

Recipients. The data are stored on our servers at Hostinger in Frankfurt am Main (§ 6.1). Twilio receives your number for the line-type check and the SMS you send (§ 6.9); transfer to the USA: § 7.

Access. The app shows whether your installation is verified, with the number partly hidden, and when a grace period ends. A copy of your data (§ 9) contains the verification data of the installations on which only your account is signed in; for an installation shared with other accounts it states only whether the installation is verified. If you no longer have the installation — for example after uninstalling the app — email support@imeterreader.app with your phone number: we compute its keyed hash, find the verification of that number and give you access to it or delete it, together with the AI usage counters of that number (Art. 15, 17 GDPR), after checking that the request comes from the holder of the number; the search is logged without the number.

19. Crash and diagnostic data (Sentry)

We use Sentry (§ 6.5) to find and fix errors quickly. Error reports come from four sources — the mobile app, our servers, our website and our staff web apps — and all go to one Sentry project of ours (EU ingest in Frankfurt am Main, *.ingest.de.sentry.io). For all four sources: email addresses, phone numbers, tokens, IP addresses and IBANs are replaced by "[redacted]" before a report is sent; our Sentry project is set not to store IP addresses ("Prevent storing of IP addresses"); no user or account identifier is attached to a report; no email address, name or username and no advertising or tracking identifier is sent; there is no performance measurement; Sentry keeps the reports for 90 days and then deletes them. For one exception on iOS see § 19.1.

19.1 Mobile app

Crash diagnostics are enabled by default. While they are enabled, the app sends to Sentry:

crash reports, reports of errors the app has caught, and the app's own log lines of error level,
breadcrumbs from the minutes before the error: the app's log lines from information level up; the requests to our servers (method, server address and path, status — no query string); screen and navigation steps (fixed screen names and titles, route names, button presses — never text you type); app lifecycle and system events (for example connectivity or battery),
at most one report per app start about problems of the previous start (its error log),
device info: manufacturer, model, operating system and version, whether the device is rooted or jailbroken, language/locale, time zone, screen, memory and storage figures, battery state,
app version and build.

Before sending, the app replaces email addresses, phone numbers, tokens, IP addresses, IBANs, account and device identifiers and URL query strings. It does not report failed requests separately, sends no performance data, and app sessions ("release health") are switched off.

Not sent to Sentry:

your IP address (the app sends none, and Sentry is set not to store it),
a user or account identifier, or an installation or device identifier (iOS exception below),
the name of your device,
your email, name or username,
contents of meter readings, contracts, chat messages or notes.

On iOS, crashes caught by Sentry's own iOS component (crashes of the app process itself, sent at the next start) cannot be fully processed by the app before sending: they can carry Sentry's installation identifier for the app, a device-specific app hash and the unredacted system error text. Our Sentry project is set to remove the installation identifier and the device-specific app hash on receipt; the system error text is kept with the report (90 days). Error messages may contain internal random record identifiers (for example of a meter). They do not name you; they are pseudonymous data.

Objection: switch off Settings → Privacy → "Crash & diagnostic reports". The objection takes effect on the device from the next start of the app — crash diagnostics are switched on once, when the app starts, so the app session that is running when you switch them off can still send crash and error reports — and it is additionally recorded server-side straight away via the device-keyed privacy-choice record (§ 21), so it is respected even without an account. If you switch off "Crash & diagnostic reports" in the app, our servers also stop sending error reports for every request from that installation and — if you are signed in — for every request of your account from any device, at the latest five minutes after the app has transmitted your choice to our servers.

19.2 Our servers

Our servers report only real server errors (errors and unhandled exceptions — not warnings and not mistakes in a request sent to us). A report contains:

the stack trace (class, method, line), the error message and the log lines written before the error — email addresses, phone numbers, tokens, IP addresses and IBANs are automatically replaced by "[redacted]" before sending,
the HTTP method and the request path (no query string, no headers, no cookies, no request body),
the thread name, the Java runtime version and the server profile.

Reports from our servers contain no user, account, installation or device identifier: where such an identifier appears in an error message or a request path it is replaced before sending; other internal random record identifiers (for example of a meter or a contract) can remain — pseudonymous data. Your IP address is not sent. Automatic redaction cannot recognise free text such as a name; we therefore do not write personal data into error messages.

19.3 Our website

If a JavaScript error occurs in your browser on our website (imeterreader.app), the site sends: the error message (redacted as in § 19.2), the stack trace (script file URLs, line and column), the path of the page, taken from the page itself, including the language (no query string, no fragment), your navigation and the site's own request paths before the error, and the Angular version. The script does not read your browser's User-Agent or referrer. Your browser transmits its User-Agent with every request, including the one to Sentry; Sentry is not asked to evaluate it. No cookies are set and nothing is stored on your device; no user identifier is sent and no IP address is stored; there is no performance measurement and no session replay. If your browser sends Global Privacy Control or Do Not Track, no error report is sent at all.

Objection: turn on Global Privacy Control or Do Not Track in your browser, or email support@imeterreader.app.

19.4 Our staff web apps

Our admin panel (admin.imeterreader.app) and our offers staff app (deals.imeterreader.app) are used only by our own staff. They report the same browser data as the website (§ 19.3). Their page and request paths can contain internal random identifiers of app users' records and accounts — pseudonymous data. A failed request is reported only as method, path, status code and the redacted error message — never with response bodies or form contents. The persons concerned are our staff and the app users whose identifiers appear in a path. Objection: by email to support@imeterreader.app; we handle it case by case and delete matching reports.

19.5 Linking an app error to a server error

With its requests to our servers the app sends a random identifier that is created anew at every app start and not stored; it is sent only to our servers and can link an app error to the server error it caused. It identifies no person and no device.

19.6 Legal basis and objection

Our legitimate interest in stable, secure software and in finding and fixing errors quickly (Art. 6(1)(f) GDPR; a documented legitimate-interest assessment / balancing test is kept on file with the controller). This processing is not consent-based. You have the right to object at any time (Art. 21 GDPR): in the app as described in § 19.1 — this also covers the error reports our servers send for your requests; on the website as described in § 19.3; for the staff web apps and for server tasks that serve no particular request, by email to support@imeterreader.app — we handle such objections case by case and delete matching reports.

20. Anonymous usage statistics (device telemetry)

To improve quality, detect stability issues and guide product development, we collect aggregated device-level usage statistics (see § 4.4). Each day we transmit:

meters count (cumulative),
contracts count (cumulative),
meter readings count (cumulative),
app opens since last snapshot,
active session minutes since last snapshot,
app version.

These data are not tied to your account, only to an anonymous per-installation UUID. If you sign in later, the UUID is linked to your account — you can sever this link at any time (Settings → Account → "My devices").

Legal basis: our legitimate interest in quality assurance, stability analysis and product development (Art. 6(1)(f) GDPR; a documented legitimate-interest assessment / balancing test is kept on file with the controller). Usage statistics are not consent-based. You have the right to object at any time with effect for the future (Art. 21 GDPR); objecting is as easy as flipping the switch (Settings → Privacy → "Anonymous usage statistics") and is additionally recorded server-side via the device-keyed privacy-choice record (§ 21). The lawfulness of processing carried out before your objection remains unaffected.

Default state: usage statistics are enabled by default. You can switch them off at first launch or at any time later in Settings.

Note: this toggle does not cover the one-time install count described in § 5 / § 4.10; it runs independently of this setting (you may object under Art. 21).

21. Device-keyed record of your privacy choices (pre-login)

So that your privacy choices are known on our servers as well — and not only on your device — the app transmits the current state of your per-option privacy settings to our backend before and without any account or login, over the unauthenticated device channel identified by the persistent per-installation device UUID (§ 4.4, HTTP header X-Device-Id).

What is transmitted and stored (server-side, keyed by the device UUID): for each option — AI meter reading (OCR), AI contract analysis, AI chat, crash diagnostics (Sentry), anonymous usage statistics and the provider-directory contribution (§ 16.6) — the option identifier and its current state, the version of this privacy policy that was shown on the device when the choice was made, the timestamp of the last change, and the platform (§ 4.11). No name, no email address, no IP address and no account identifier are part of this record.

Purpose: to record the device's privacy choices so that the device's current choice state is known on our servers and demonstrable (Art. 5(2), Art. 24 GDPR). Your choices are enforced by the app itself: it does not send your data for a consent-based feature (for example a meter photo for cloud AI processing) unless you have given that consent, and it stops crash diagnostics and usage statistics once you object. Our servers do not themselves accept or refuse a request on the basis of this record.

Lawful bases:

Storing and evaluating the device-keyed record itself: Art. 6(1)(f) GDPR — legitimate interest in knowing and documenting your privacy choices server-side.
The recorded choices for AI meter reading, AI contract analysis and AI chat are your consents (Art. 6(1)(a), Art. 7 GDPR), stored as granted or withdrawn; these features remain off until you consent (§ 16).
For crash diagnostics (Sentry), anonymous usage statistics and the provider-directory contribution, which run by default on the basis of legitimate interest (Art. 6(1)(f); §§ 16.6, 19, 20), the record stores your objection state (objected / not objected) under Art. 21 GDPR. It is deliberately never stored as a "consent", because a default-on setting is not consent (Art. 4(11), Art. 7 GDPR).

Integrity note: because this channel works without a login, the device-keyed record is operational current-state information reported by the device. It is not used as evidence of consent within the meaning of Art. 7(1) GDPR. That evidence lives in the account-bound consent log (§ 4.8), which is written only for authenticated users. The operator can view the device-keyed state read-only in the administration back office, where it is marked accordingly.

Retention and erasure: if the device is never linked to a user account, the record is deleted at the latest 18 months after the device was first seen — regardless of which states are stored. If you delete your account (Art. 17 GDPR), the device's privacy-choice records are deleted as well and the device reverts to install-only status (§ 4.10). You can also request deletion at any time via support@imeterreader.app.

Recipients: the record is stored exclusively on our servers at Hostinger in Frankfurt am Main, Germany (§ 6.1). No third-country transfer takes place.

22. Children under 16

iMeter Reader is intended for adult energy customers. It is not intended for children or adolescents under 16. We do not knowingly process data of persons under 16. If we learn that such data has been provided without valid parental consent, we delete it without delay.

23. Changes to this privacy policy

We update this privacy policy whenever our processing or applicable law changes. We give at least 30 days' notice of material changes — via an in-app notice and (if you have an account) by email. Changes that only add optional features you must switch on yourself, or that correct or clarify existing statements without reducing your rights, take effect on publication. The current version is always at:

https://imeterreader.app/en/privacy

Version 2.19 of 20 October 2026 — error reports (Sentry) now also from our servers, our website and our staff web apps; app error reports described in full (§§ 4.6, 5, 6.5, 8.1, 8.2, 9, 19, "Visiting our website", Annex A):

New sources (§§ 19.2–19.4). Besides the mobile app, our servers, our website (imeterreader.app) and our two internal staff web apps (admin.imeterreader.app, deals.imeterreader.app) now send error reports to the same Sentry project (EU ingest in Frankfurt, 90 days, no IP addresses stored). Email addresses, phone numbers, tokens, IP addresses and IBANs are replaced by "[redacted]" before sending. Reports from our servers carry no user, account, installation or device identifier; paths in the staff web apps can contain the internal identifier of an account — pseudonymous data.
Website (§ 19.3, "Visiting our website"). JavaScript errors in your browser are reported without cookies and without storing anything on your device; the script reads neither your User-Agent nor the referrer; no performance measurement, no session replay. If your browser sends Global Privacy Control or Do Not Track, nothing is sent. You can object via these signals or by email (§ 9).
Mobile app (§§ 4.6, 19.1). We now describe in full what the app sends: crash reports, reports of caught errors and error-level log lines; breadcrumbs (log lines, requests to our servers without query string, screen names and button presses, system events); at most one report about problems of the previous start; the device info listed in § 19.1. The app replaces email addresses, phone numbers, tokens, IP addresses, IBANs, account and device identifiers and query strings before sending; it sends no installation identifier (except in crashes caught by Sentry's own iOS component, § 19.1) and no performance data, and app sessions ("release health") are switched off. A random identifier created anew at every app start can link an app error to the server error it caused (§ 19.5).
Objection (§§ 5, 9, 19). Switching off "Crash & diagnostic reports" in the app also stops the error reports our servers send for the requests of that installation and — if you are signed in — of your account.
Unchanged: legal basis Art. 6(1)(f) GDPR, no consent (§ 5); same sub-processor, location, transfer safeguards and DPA (§ 6.5, Annex A). No renewed consent is required — none of these changes affects processing based on Art. 6(1)(a) GDPR.

In-place amendment of 20 October 2026 (§§ 9, 19) — correction, no change to the processing: switching off "Crash & diagnostic reports" takes effect on the device from the next start of the app, not immediately: crash diagnostics are switched on once, when the app starts. The objection is still recorded server-side straight away (§ 21). Usage statistics stop immediately, as before.

Version 2.18 of 16 October 2026 — provider directory built from company details in your contract documents (new § 16.6; §§ 4.11, 5, 8.2, 16.2, 21):

New § 16.6. After a successful AI contract analysis the app may report the company contact details found in the document (supplier's legal name, address, customer-service email, phone, website, energy type) to our provider directory, so that the cancellation assistant can offer every user the right contact and cancellation channel. Nothing about you, your contract or your account is included; the device UUID is used only for a daily limit and is not stored with the entry. Suggestions are checked by hand before they become visible.
Legal basis and objection. Art. 6(1)(f) GDPR, enabled by default, with a right to object (Art. 21) via Settings → Privacy → "Help improve the provider directory"; the objection state is recorded like the other default-on options (§§ 4.11, 21). No renewed consent is required: the scope of the AI contract-analysis consent (§ 16.2) is unchanged; the directory report is a separate, objectable processing.
Feedback and retention (§§ 8.2, 16.6). One-tap feedback on a directory entry stores a counter and, for 30 days, a one-way hash of device UUID and entry. Rejected suggestions: 12 months; unconfirmed suggestions: 24 months after the last report.

In-place change of 14 October 2026 (before this version was published) — sections on energy offers taken out: the sections on energy offers ("Deals for your area", help calls, delivery ledger, offer selection — former § 4.12 in part, § 6.13, §§ 18a and 18b, the related rows of §§ 5, 8.2, 9 and Annex A, and the related sentences in §§ 4.2, 4.4, 4.8, 6.12, 7, 8.1, 10, 12, 13, 15, 18, 18c and 21) were taken out because the service is not offered yet. § 18a now says only that the service is not yet available. The amendment entry of 14 October 2026 on those sections was moved with them; both are kept internally and return to this policy before the service starts. No data for these functions is processed. The verification of your German mobile number (§ 18c) stays, because it is required for the AI features.

Fifth in-place amendment of 13 October 2026 (§ 4.3 — two-direction (solar) meters) — made before this version was published; no new recipient, no new purpose:

Two-direction (solar) meters (§ 4.3, amended in place on 13 October 2026). § 4.3 now names the two-direction (solar) meter as a third meter mode, the two registers of its readings (taken from the grid / given to the grid), the feed-in remuneration per kWh you may enter for its contract, and the energy given to the grid per day together with the approximate feed-in earnings calculated from it, which are calculated and kept on your device only. These are data you enter yourself, for the same purpose as before (Art. 6(1)(b) GDPR): no new recipient, no new purpose, no new sub-processor and no third-country transfer. No renewed consent is required.

Fourth in-place amendment of 6 October 2026 (§§ 4.2, 4.12, 5, 6.9, 7, 8.1, 8.2, 9, 12, 13, 16.4, new § 18c, 23, Annex A — verification of your German mobile number) — made before this version was published; new processing and a sub-processor that is now active:

New § 18c — verification of your German mobile number. From the date on which we introduce the verification, the AI features (meter-photo reading, contract analysis, AI chat) are available only on an installation that has verified a German mobile number. You verify it by sending us a prepared SMS ("IMR" and a 6-digit code) from that number; we never send an SMS. The verification belongs to the installation, not to an account. If the same number is verified on another installation, the verification moves there. Installations that used these functions before the introduction can keep using the AI features for 30 days without a verification. Switching functions off, withdrawing consents and cancelling are never blocked. Codexo staff can mark an installation as verified, without any number, for app-store review for 14 days; this is logged.
What we store (§§ 4.12, 8.2). A keyed hash of the number (a pseudonym, not the number) and a partly hidden form, status, source and times — at the latest until the installation has not been active for 18 months; a pending code as a keyed hash (valid for 10 minutes, deleted 24 hours after it expired); the line-type result of a number (30 days); a keyed hash of the message ID of your SMS (7 days); AI usage counters per verified number (at most 31 days); grace-period records (30 days after the end of the grace period).
Twilio is now an active sub-processor (§§ 6.9, 7, Annex A). Twilio Ireland Limited / Twilio Inc. receives your number for a line-type check (mobile, landline or VoIP) and the SMS you send to our German mobile number. Twilio keeps the message log of our number for 7 days, with text and sender number redacted. The line-type check takes place at Twilio Inc. in the USA. Transfer to the USA on the basis of the EU–US Data Privacy Framework (Twilio Inc. is certified) and the Standard Contractual Clauses. The earlier description of a prepared, inactive SMS sending function for mobile-number verification has been removed: we send no SMS. The mobile number in your profile (§ 4.2) is not verified.
Legal basis. Art. 6(1)(b) GDPR (you ask for the verification to use these functions) and Art. 6(1)(f) GDPR (preventing misuse and fraud, and offering these functions only in the German market); the grace period is decided with records we already held, in your favour (Art. 6(4) GDPR). You may object; removing the verification in the app has that effect.
Consequential changes. § 12 states that the verification is required for these functions; § 13 explains the automatic refusal of numbers that are not German mobile numbers; §§ 8.1, 9 and 16.4 refer to § 18c.
Renewed consent. The verification is not based on consent and does not change the scope of any consent, so no renewed consent is required. Data reach Twilio only when you start a verification yourself. Users who already use the AI features keep them for 30 days after the introduction without a verification.

Version 2.16 of 3 October 2026 — corrections:

Binding language version. The English, Arabic and Turkish versions of this policy are now marked as courtesy translations; the German version is legally binding.
Correction (§ 18): earlier versions said that each time the app sends or renews its push registration, our server records that the installation was seen and updates its app version. It no longer does: sending or renewing the registration only updates the registration itself, and whether an installation was seen comes only from the anonymous usage statistics (§ 20). § 18 and § 8.2 now describe the 270-day deletion of registrations accordingly.
Correction (§§ 5, 21): § 21 said, as an example, that our backend refuses cloud AI processing for a device whose record shows no consent. That was inaccurate: your privacy choices are enforced by the app, which does not send your data for a consent-based feature without your consent; our servers do not accept or refuse requests on the basis of the device-keyed record. §§ 5 and 21 now say so.
Correction (§§ 4.4, 20): the daily usage statistics also contain the number of meters on the device. Current app versions already transmit it; the lists in §§ 4.4 and 20 did not name it.
Completion (§§ 8.1, 12): the lists of transmissions that occur without an account now also name the push registration (§ 18), which has been described in § 18 since version 2.14.
Business name. This version incorporates the in-place amendment of 18 September 2026 (business name Codexo, below), which is published for the first time with this version, and the in-place amendments of 15 and 11 September 2026; the header no longer lists the individual in-place amendments.
Renewed consent and effective date. None of the other changes affects processing based on Art. 6(1)(a) GDPR for the AI features, so no renewed consent is required for them; this version takes effect on publication.

In-place amendment of 18 September 2026 (header, § 1 — business name) — no change in processing:

Business name Codexo. The operator has registered a trade (Gewerbeanmeldung) under the business name Codexo, with effect from 1 September 2026. The header and § 1 now name the controller as Codexo, the sole proprietorship of Ahmad Al Alloush, and the placeholder note about the pending business registration has been removed. A sole proprietorship is not a separate legal entity, so the controller has not changed: it is still Ahmad Al Alloush, now trading as Codexo, at the same address and with the same contact address. No new recipient, no new sub-processor, no third-country transfer, no change to purposes, legal bases or retention periods. No renewed consent is required.

In-place amendment of 15 September 2026 (§ 23 — activation date of per-meter postcode synchronisation) — no change in processing:

15 September 2026 — per-meter delivery-point postcode synchronisation to our servers in Frankfurt, Germany was activated from this date. The postal code you enter for a meter, and the locality derived from it on your device, are transmitted and stored with that meter's record when you are signed in (Art. 6(1)(b) GDPR), exactly as §§ 4.3, 5 and 17 have described since version 2.13. Before this date the server received these two fields but did not store them; from this date it stores them. A postal code saved on a meter before this date reaches our servers the next time that meter is saved. You can change or clear the postal code at any time in the meter's edit form; clearing it also clears the derived locality, on your device and on our servers. No new recipient, no new sub-processor, no third-country transfer, no change to purposes or retention periods. No renewed consent is required — this processing rests on Art. 6(1)(b) GDPR.

In-place amendment of 11 September 2026 (§§ 6.9, 15) — no change in processing:

§ 6.9: the Twilio Inc. entry (SMS verification) now states in the paragraph itself what Annex A and this section already said: prepared, not active; the transfer is described generically as "outside the EEA". No SMS is sent and no data reaches Twilio until the function is activated, which we will announce here beforehand.
§ 15: the list of sign-in data held in the operating system's secure store is complete again: access, refresh and ID token, their expiry times, user ID, username, display name and email address. Which sign-in method you used is not stored.

Version 2.15 of 9 September 2026 — correction of the sign-in and email sections (§§ 4.1, 4.2, 5, 6.2, 6.9, 6.11, 7, 14, 15, Annex A):

What was wrong. Versions 2.12 to 2.14 of this policy described a planned change to our sign-in system as if it had already taken place: registration with a German mobile number verified by SMS, accounts managed by our own application, the identity service at auth.codexo.dev "decommissioned", all email sent from our own mail server, and Twilio SendGrid "removed as a sub-processor". None of that has been rolled out. The app you can install today — and every version before it — signs you in through our self-operated identity service (Keycloak at auth.codexo.dev, running on our Hostinger servers in Frankfurt am Main, § 6.2); an account is created with an email address and a password, or through Google or Apple (§ 6.11); no SMS verification is active; and account emails (confirmation of your address, password reset, operator service messages) are delivered by Twilio SendGrid, USA (§ 6.9, Annex A) — exactly as versions up to 2.10 described. This version restores that description. The incorrect text was served from 15 August 2026 until this version was published.
What changed in substance — nothing. Between version 2.10 and today no processing, recipient, purpose, legal basis or retention period in these sections changed; only the description was wrong. Twilio SendGrid was never removed: it was disclosed in version 2.10 and earlier, and its entries in § 6.9 and Annex A are restored unchanged. The SMS entries (Twilio Inc., §§ 4.2, 6.9, Annex A) are restored as version 2.10 stated them: prepared, not active.
§ 6.11 — sign-in with Google or Apple. The first paragraph now states correctly that the browser first contacts our own sign-in server at auth.codexo.dev and is forwarded from there to the provider you chose; the sentence "Since version 2.12 there is no intermediary identity service" was deleted. Google and Apple remain independent controllers for their own sign-in processing, as before.
§§ 5, 14, 15. The security event log of failed sign-in attempts is kept by our identity service (IP address, username, timestamp), as § 8.2 already stated; § 5 was aligned with it. § 14 again names both pinned hosts (auth.codexo.dev, imeterreader.codexo.dev) and the Keycloak admin role. § 15 states that the identity-service cookie is set during every sign-in, not only during sign-in with Google or Apple.
No processing based on Art. 6(1)(a) GDPR is affected, so no renewed consent is required. This version corrects the description of recipients and processing that were already disclosed in version 2.10 and introduces no new recipient, purpose or transfer; it therefore takes effect on publication.

Version 2.14 of 7 September 2026 — service push notifications:

Service push notifications (new § 18, new § 6.12). The app can now receive service notifications from us. Up to version 2.13 this policy stated that no push tokens were transmitted; from the first app version released after 7 September 2026 that is no longer true, and this policy was published before that app version was released. A Firebase Cloud Messaging registration token, your platform, app language and app version are transmitted to our servers and the token to Google (Firebase Cloud Messaging, new sub-processor, § 6.12, Annex A) — only while you have granted the operating-system notification permission; on iOS, Apple Inc. (Apple Push Notification service) additionally receives each notification for delivery. The Firebase software component is initialised at app start and creates an installation identifier with Google regardless of the permission (§ 6.12). Legal basis Art. 6(1)(f) GDPR (Art. 6(1)(c) for legally required notices); not consent-based, no in-app opt-in; you object by switching notifications off in your device settings (§ 18). §§ 4.4, 4.9, 5, 7, 8.2 and 9 were amended accordingly. This is a new recipient and a possible third-country transfer (Google LLC, USA — SCCs + Data Privacy Framework). Reminders remain local notifications.

This change does not affect processing based on Art. 6(1)(a) GDPR, so no renewed consent is required for the AI features.

Version 2.13 of 9 August 2026: § 4.3 now distinguishes between the supply address (street / house number), which stays exclusively on your device, and the per-meter postal code of the delivery point together with the locality derived from it: the latter two are part of the meter record and are transmitted to and stored on our servers in Frankfurt am Main when you are signed in and meter sync is active. The corresponding row in § 5 has been corrected accordingly, and § 4.9 clarifies that a postal code you enter yourself, and the locality derived from it offline, are not location data in that sense. Legal basis unchanged — Art. 6(1)(b) GDPR; no new recipient, no new sub-processor, no third-country transfer, no change to retention periods. No renewed consent is required — none of these changes affects processing based on Art. 6(1)(a) GDPR.

In-place correction of 7 August 2026 (Version 2.12 unchanged): §§ 8.1 and 8.2 previously described the data on your device as a local SQLite database and stated that the "Delete account" function wipes it before the server call. We have removed the storage-technology name — an implementation detail that can change from release to release — and corrected the sequence: the copy on your device is removed after our servers have confirmed the deletion request, never before. Both passages now also state that the settings which configure the app on this device deliberately remain. No purpose, legal basis, recipient or retention period changed, and the scope of your consent is unaffected — no new consent is required.

Annex A — List of sub-processors (as of 2026-10-20)

Name	Location	Role	Data location	Third-country transfer	DPA
Hostinger International Ltd.	Kaunas, LT (EU)	Hosting (compute, DB)	Frankfurt am Main, DE	none	Hostinger DPA
AKI.IO GmbH (sole sub-processor: AIME GmbH, Berlin)	Berlin, Germany	AI model inference (meter reading, contract analysis, chat)	Germany / EU	none	Data processing agreement under Art. 28 GDPR
Functional Software Inc. / Sentry GmbH	San Francisco, USA / Berlin, DE	Crash and error diagnostics for the mobile app, our servers, our website and our staff web apps — § 6.5, § 19	Frankfurt am Main, DE (ingest); intra-group US possible	partly	Sentry DPA + SCCs + DPF
Twilio Ireland Limited / Twilio Inc.	Dublin, IE / San Francisco, USA	Verification of your German mobile number: line-type check of the number and receipt of the SMS you send to our German mobile number (we send no SMS) — § 6.9, § 18c	EU (Ireland region) for our number and its messages; USA for the line-type check	yes	Twilio DPA + DPF + SCCs
Twilio SendGrid	Denver, USA	Transactional and operator-initiated service/administrative email delivery	USA	yes	Twilio/SendGrid DPA + SCCs + DPF
Google Ireland Ltd. (ML Kit + Play Services)	Dublin, IE	Local OCR model on Android	on device	intra-group US possible	Google Cloud Customer Mobile Services DPA
Apple Inc. (Vision framework)	Cupertino, USA	Local OCR framework on iOS / macOS (OCR only — sign-in is not a processor relationship, see § 6.11)	on device	none (no data transfer)	Apple Developer Program License Agreement
Google Ireland Ltd. (Firebase Cloud Messaging)	Dublin, IE	Delivery of service push notifications (installation identifier, registration token, platform, notification content) — § 6.12, § 18	EU; intra-group transfer to Google LLC (USA) possible	possible (SCCs + DPF)	Google Cloud / Firebase Data Processing and Security Terms
Apple Inc. (Apple Push Notification service)	Cupertino, USA	Delivery of service push notifications to iOS devices (APNs token, notification content) — § 6.12, § 18	USA	yes (DPF)	Apple Developer Program License Agreement

Google and Apple additionally act as independent controllers when you choose to sign in with them (§ 6.11). They are not our sub-processors for that flow and are therefore not listed in the table above.

We update this list as our infrastructure evolves. The current version is at https://imeterreader.app/en/subprocessors. We notify users of new sub-processors at least 30 days before introduction.

iMeter Reader privacy policy · Version 2.19 · 20 October 2026 · Privacy questions: support@imeterreader.app

Privacy | Terms | Sub-processors | Imprint | support@imeterreader.app