Privacy policy
TALLY2AI PRIVACY POLICY
Version: 2026-09-07.2
Publisher and responsible organisation: Infisto Technologies LLP
Contact: legalteam@tally2ai.com
Website: https://tally2ai.com
This policy describes the official Tally2AI Windows program and our membership, download, update and analytics services. Version 1.3.0 introduced membership verification and optional verified-email analytics. Version 1.3.2 adds optional approximate-location analytics and person-profile processing for usage events. These flows apply when using that release and its configured services; this notice does not claim a particular deployment is already live. It does not cover an independent AI app or other software you choose to connect. Membership verification is required for protected app features; usage reporting is optional and is not required to use REST, MCP or updates.
1. What stays on your computer
The bridge reads and changes Tally data only through its supported local integration and permissions. Its local state may contain cached accounting records, company identifiers, mutation journals, configuration, access grants and limited access logs. These are kept in the current Windows user's protected application-data directory. Credentials use Windows user protection; accounting databases rely on filesystem access controls and are not automatically encrypted by that credential protection. A local receipt records the agreement version and acceptance time; this receipt is not sent as analytics.
Local processing is needed to provide the features you request. Keeping an app on localhost does not make the whole computer secure: software running as your Windows user, administrators and anyone controlling the machine may access local data. Tally's own XML listener is outside the bridge's access controls.
2. Data sent to apps and AI services you connect
Approved REST or MCP clients receive the records, reports and results allowed by the permissions and companies you select. This can include personal, financial, tax and confidential business information. A client may forward those results and its prompts to an AI model or other cloud service under that provider's policies. Tally2AI cannot promise how an independently chosen client stores, trains on, retains or shares the information it receives. Review the client and provider's terms before granting access. Use read-only and the fewest necessary company permissions, review actions and revoke unused access.
The official analytics pipeline described below does not send accounting records to an AI model. There is no blanket permission in this policy to use your books or prompts to train AI models.
3. Membership verification and optional usage reporting
To activate version 1.3.0, enter the email address associated with your Tech Essentials membership at https://techessentials.in and verify the sign-in code. Our membership service on Cloudflare receives your email, a generated device public key and identifier, sign-in requests and device proof. It sends the code through Cloudflare Email Sending and checks membership through the blog's Ghost Admin API. The blog is hosted by Magic Pages. Ghost membership status and, when relevant to the access rule, subscription and tier information determine eligibility. This is separate from optional analytics and does not send accounting records to Cloudflare, Ghost or Magic Pages.
Our service stores encrypted email addresses, generated device identifiers/public keys, opaque membership indexes, verification timestamps, and keyed verifiers for short-lived codes and renewal credentials. The device identifier is derived from a generated key, not a hardware serial number. Rate controls use address-derived keyed indexes. Cloudflare's email infrastructure necessarily receives the recipient and code to deliver it; our database stores a verifier rather than the plain code and message previews are disabled. The code is not sent to analytics. Your computer stores its membership credentials protected for your Windows account.
The initial policy permits free members and two computers per member, with a signed access period of up to 24 hours after verification. Publisher rules can change eligibility, tiers, device limits and offline duration. The app reuses its valid signed access period across requests and restarts. Under the initial policy, it checks membership about once per day, at expiry on the next protected use or status check; it does not run an independent continuous renewal service. Shorter policy or paid-membership deadlines are honoured, and there is no additional offline grace after expiry. Sign-in may be needed again after a failed or uncertain renewal. An offline access period cannot be extended by a failed check. Signing out removes local membership credentials; if the service is unreachable, releasing that computer's server-side slot may require assistance. Stopping optional analytics does not stop required membership checks.
New installations of version 1.2.2 onward show reporting enabled by default during first-run setup. You can uncheck the reporting option before accepting and continuing. Version 1.3.2 sends no new usage events or verified-email identification until the current setup disclosure is accepted and reporting is enabled. Existing saved off choices stay off. Earlier 1.2.1 releases default reporting off and require enabling it. You can change the setting later in Settings > Privacy & analytics. Turning it off does not disable the bridge, REST, MCP, update checks or downloads, subject to the separate membership requirement.
When reporting is enabled, the app sends a random installation identifier, random event identifier, app version, operating-system family (Windows), processor architecture, stable release channel, named startup/update/REST/MCP/owner activity, and, when relevant, a target update version. Usage events include only fixed operation or tool names, coarse success/error categories and response-time buckets. The service records receipt time. Random identifiers are pseudonymous, not a guarantee of anonymity, and can link events from the same reporting installation.
For version 1.3.2 and later, after this disclosure is accepted with reporting enabled, Cloudflare adds approximate country, region, city and time zone from the analytics request to usage events. We forward these coarse location fields to PostHog and may store them on the reporting person profile. This is network-derived location, not GPS; VPNs and network routing can make it inaccurate. Raw IP addresses, postal codes and geographic coordinates are not forwarded by this analytics pipeline. Existing older event formats retain their previous restricted processing.
After membership verification, if reporting is enabled and the current disclosure is accepted, our membership service also sends your verified email address and an email-verified flag to our PostHog EU project, linked to the reporting installation identifier. This creates or updates a person profile and makes associated usage identifiable. The email comes from the verified membership record, not an arbitrary address supplied with an analytics event. This helps us understand how members use the app and prioritise improvements. Activity associated with that identifier can be linked to the email, including earlier events under the same identifier. Changing signed-in members rotates the local reporting identity to avoid attributing one member's future activity to another.
Ordinary usage event payloads do not contain email addresses; email identification uses the separate verified membership route. Both exclude company names and identifiers, GST numbers, ledger names, transactions, balances, raw request or response bodies, prompts, tool arguments or results, Windows usernames, filesystem paths, credentials and raw error messages. Reporting measures supported feature use and reliability. We do not sell these reports or use them for targeted advertising.
4. Who receives reporting and network data
Reporting is sent over HTTPS to b.tally2ai.com. Older builds use events.tally2ai.com, which remains supported. Both are Infisto's endpoints on Cloudflare. Cloudflare processes network information, including IP addresses, to deliver and protect its services. The application analytics database does not store visitor IPs; an address-derived daily keyed value is used for short-lived request limiting.
Cloudflare stores accepted reporting events in its D1 service and briefly queues an allowlisted message for PostHog. PostHog receives that event metadata in our EU-hosted project for charts and analysis. Ordinary event forwarding uses a separate queue context and sends no original visitor headers. New disclosed event formats enable person-profile processing and include the approximate location fields described above, briefly carried in the forwarding queue; the application D1 event table does not store those location fields. Older event formats retain disabled location enrichment and ordinary-event person-profile creation. The separate verified-email identification request deliberately creates or updates a PostHog person profile when enabled as described above; it is sent directly rather than queued. Neither flow intentionally forwards the user's IP address to PostHog. Cloudflare and PostHog use their own subprocessors and service operations; EU project hosting is not a promise that every supporting operation occurs only in the EU.
Downloading the app, checking for updates or visiting the website makes network requests to Cloudflare even with reporting off. Network providers necessarily see connection metadata; this is separate from optional usage events. The public website does not embed a PostHog browser SDK, advertising tracker or session recorder. The restricted publisher dashboard uses an essential, short-lived sign-in cookie. Security and delivery providers may process service logs under their policies.
Provider information: https://www.cloudflare.com/privacypolicy/ and https://posthog.com/privacy . Processing may occur outside your country. We remain responsible for our obligations under applicable law; third-party involvement does not automatically remove them.
5. Retention and turning reporting off
Cloudflare application reporting rows are deleted by a daily job after 90 days; deletion is subject to job execution and does not promise immediate erasure from every provider backup. Queued forwarding messages expire within 24 hours. A message already accepted by the server may still finish forwarding after you turn reporting off. The setting stops new application reports, aborts in-flight local sends where possible and clears the local reporting identifier. It cannot recall a request already delivered.
PostHog retention is separate. At our last recorded project check, it displayed a 12-month setting with automatic event-retention enforcement inactive. We therefore do not promise automatic deletion from PostHog on that date. Events and person profiles remain until deleted through an applicable retention or deletion process. Contact us to request deletion of identifiable reporting records; where necessary, we will coordinate with the provider. You can provide your verified membership email to help locate an identified profile. Earlier unlinked reports may require a reporting identifier. Never send configuration or credential files. Changing or resetting an installation identifier does not itself delete older records or erase an existing email-linked profile; if reporting stays enabled after a reset, verified-email identification can link the new identifier again.
The membership service schedules hourly cleanup of expired sign-in challenges more than one day after expiry, expired rate budgets, device records more than 30 days after their renewal credential expires, and administrative audit entries older than 90 days. A renewal credential normally lasts 30 days and is replaced on a successful check. Cleanup depends on the scheduled job operating successfully; it is not immediate deletion from all provider backups. The separate mapping that prevents a reporting identifier being reassigned to another member or device has no automatic expiry in this release. Contact us for deletion requests; removing membership records may require fresh activation. Ghost's membership records and email-provider delivery records have separate retention policies. Signing out does not delete the Ghost membership or previously retained reporting data.
Local caches, journals, access settings and agreement receipts remain on your computer until removed under your control; ordinary uninstall may retain protected state for recovery. They are not erased by turning reporting off. Keep accounting backups according to your own obligations.
6. Messages you send us and your choices
If you email us, we receive your email address, message and attachments to respond and handle the request. Send the minimum needed and avoid accounting records, passwords, private signing keys or access tokens. We keep correspondence as needed to address the request and meet applicable obligations.
Depending on applicable law, you may have rights to information, access, correction, deletion, withdrawal or objection, and to complain to a competent authority. Contact legalteam@tally2ai.com for privacy questions or requests. Include only information needed to locate the relevant data; we may need reasonable verification before acting. We will address requests within applicable legal time limits, explain any lawful restriction, and will not require unnecessary accounting data. These terms do not waive any privacy right. Infisto is responsible for determining and meeting the legal requirements applicable to its processing; a preselected reporting setting is not a claim of valid consent in every jurisdiction.
7. Security and AI risks
We apply measures such as loopback-only bridge access, owner-approved client permissions, credential protection, strict reporting fields, HTTPS for hosted traffic, bounded requests, and cryptographically verified update metadata. Safeguards have limits and must be maintained. No system or AI model can guarantee complete protection against vulnerabilities, compromised devices, mistakes, data disclosure or increasingly capable AI-assisted attacks. The program does not contain a universal AI security filter. Independently connected AI systems can make errors or act on malicious instructions; do not rely on them as the sole reviewer of financial changes.
We will handle security incidents and any legally required notices under applicable law. This policy does not disclaim duties that cannot lawfully be excluded. Please report suspected security issues privately through our contact address rather than publishing credentials or customer data.
8. Audience and policy changes
The program is intended for adults acting personally or for businesses, not for children. Do not knowingly submit children's information through optional reporting. We will publish updated policies with a new version and provide any notice or choice required for a material change. Installed programs retain their own versioned setup record; accepting an earlier version does not establish acceptance of every future change.