Terms of Service

Publication note

These Terms identify the GeriPay service as being operated by Vedat Ellidokuzoglu, an individual sole proprietor based in Illinois, United States. Legal, privacy, rights-request, support, and general legal-material questions may be directed to legal@geripay.com.

Section 1. Introduction and Agreement Framework

1.1 Service relationship and document role

These Terms of Service form a binding agreement between Vedat Ellidokuzoglu, an individual sole proprietor operating the Service under the GeriPay brand from Illinois, United States ("GeriPay," "we," "us," or "our"), and the person or organization that accesses or uses the Service. Where the Service is accessed, configured, or used on behalf of an organization, that organization is the Customer for organization-governed workspace use, and the individual acting through the Service does so in both a personal and representative capacity to the extent applicable under these Terms.

The "Service" must be read broadly throughout this agreement. It includes GeriPay's websites, hosted application surfaces, onboarding and invite flows, member- and admin-facing Workspace surfaces, receipt-upload and storage flows, SmartScan and related extraction tools, reimbursement-request workflows, payout-method and Payment History features, Report and export generation, Verified PDFs, Verification Codes, the Public Verification Page and other public or semi-public verification surfaces, support and troubleshooting channels, legal-acceptance evidence and audit-evidence flows, monitoring and security features, and related technical, provider-supported, operational, and successor functions. The Service also includes generated records, derived records, statuses, metadata, audit trails, and other artifacts created in the ordinary course of operating those surfaces, even if users do not directly view every component.

The fact that the Service touches sensitive operational, reimbursement-adjacent, payment-adjacent, reporting, verification, or evidence-related subject matter does not change the basic nature of the Service. GeriPay provides software and related technical services for record capture, workflow support, storage, display, routing, review, generation, export, and administration. These Terms should therefore be read from the outset as an operational-software agreement, not as a contract under which GeriPay agrees to perform banking, settlement, payroll, tax, accounting, legal, compliance, approval, certification, or other regulated or professional functions.

1.2 Acceptance mechanics and binding effect

You agree to these Terms by creating an account, accepting an invitation, completing an electronic acceptance flow, entering a typed name, clicking a button or checkbox that indicates acceptance, accessing or using a workspace, using a public or code-enabled portion of the Service where these Terms are presented or incorporated, or otherwise accessing or using the Service after a reasonable opportunity to review these Terms. If you do not agree, you must not access or use the Service.

You may not avoid these Terms by claiming that you did not read every line after completing an acceptance flow, accepting access, or using the Service. If you continue to access or use the Service after updated Terms become effective in a manner permitted by law and these Terms, that continued access or use may also constitute acceptance of the updated Terms.

GeriPay may preserve, where available and as applicable to the relevant acceptance flow and system state, records showing the version presented, the manner of acceptance, related acceptance metadata, and supporting chronology. Unless these Terms expressly provide another update mechanism, the version presented at the time of the relevant acceptance event will control for that event.

1.3 Organization binding and representative capacity

If you create an account, accept an invitation, configure a workspace, or otherwise access or use the Service on behalf of an organization, you represent and warrant that you have authority to bind that organization to these Terms for the scope of that access and use. You also represent and warrant that the organization is authorized to provide access to the persons it invites, authorizes, manages, or permits to use the Service through its workspace.

GeriPay may rely on reasonable authority signals, including business-domain use, organization-managed invitation flows, workspace role assignments, admin designations, and other apparent-authority indicators, unless GeriPay has actual contrary knowledge. The organization remains responsible for workspace-governed conduct by persons it authorizes, invites, manages, or knowingly permits to use the Service.

If you lack authority, exceed authority, use stale authority, or misrepresent your role, identity, or organizational relationship, you may still be personally bound by these Terms and personally responsible for your access, use, misrepresentation, and resulting harm. You must promptly notify GeriPay and, where applicable, the relevant organization if your authority ends, becomes disputed, or materially changes.

1.4 Supplemental terms, feature rules, and service notices

Certain parts of the Service may be subject to additional or more specific rules, notices, or supplemental terms, including rules for uploads, reimbursement workflows, payout-method handling, reports, verification features, beta features, public surfaces, or security-sensitive functionality. Unless GeriPay expressly states otherwise in a binding written supplement, those additional materials supplement these Terms rather than replace the core allocation, disclaimer, liability, and enforcement structure set out here.

If a direct conflict exists between these Terms and a feature-specific supplement expressly designated by GeriPay as controlling for a specific feature, that feature-specific supplement will control only to the extent of the direct conflict and only for that feature. No support message, marketing statement, workflow badge, public label, short help description, status term, or similar informal content will expand GeriPay's obligations unless GeriPay expressly states in a binding written supplement that it is doing so.

1.5 Changes to the Service and changes to these Terms

GeriPay may add, remove, pause, restrict, redesign, rename, regroup, replace, or discontinue any feature, module, workflow, provider, file format, model, delivery method, public-surface behavior, or operational step in the Service at any time. GeriPay is not required to preserve the same screens, labels, workflow order, file paths, verification behavior, provider stack, or legacy feature structure over time.

GeriPay may also revise these Terms from time to time. Notice of revised Terms may be provided through the Service, by email, through an updated acceptance flow, or by another method GeriPay reasonably selects. Some changes may require a new acceptance flow; others may become effective through notice and later continued use to the extent permitted by law. Not every operational change requires a separate contract amendment, and not every contract update means every feature changed.

1.6 Order of precedence and integrated document set

These Terms are part of a broader document set that may include the Privacy Policy, feature-specific supplements, invite materials, account and security notices, workflow instructions, report legends, public verification messaging, and other materials expressly incorporated by GeriPay. Those materials do not all perform the same legal function. In general, these Terms govern access, permitted use, risk allocation, disclaimers, liability limitations, and dispute handling, while the Privacy Policy governs disclosure about information handling, unless either document expressly states otherwise.

If a direct conflict exists, these Terms control questions of contract formation, scope, use restrictions, role disclaimers, warranties, liability, indemnity, and disputes, while the Privacy Policy controls questions of information handling and disclosure. Feature-specific supplements expressly designated as controlling may govern that specific feature to the extent of a direct conflict. Informal support guidance, UI labels, status words, marketing descriptions, and other short-form content do not override these Terms and should not be interpreted as independent warranties, certifications, or service commitments.

1.7 Business-use framing and anti-consumer-overreach guardrails

The Service is designed primarily for organizations and their authorized users in operational, recordkeeping, reimbursement-adjacent, reporting, verification, and internal-governance contexts. Even where some surfaces are public or semi-public, including legal pages, the Public Verification Page, or other public or semi-public verification surfaces, the Service is not offered as a general-purpose consumer finance, payroll, reimbursement-guarantee, or public certification product.

You are responsible for determining whether use of the Service is appropriate, lawful, and consistent with your or your organization's own legal, regulatory, tax, accounting, employment, reimbursement, recordkeeping, and internal-policy obligations. GeriPay may refuse, limit, or condition access where it believes a user, organization, jurisdiction, use case, or risk profile is unsuitable for the Service.

Section 2. Defined Terms and Interpretation Rules

2.1 Core defined terms list

As used in these Terms, the following definitions apply unless a section expressly states otherwise or the context clearly requires a narrower or more general reading. These definitions are intended to stabilize the contract's vocabulary without freezing GeriPay to one present-tense interface, file structure, provider stack, or workflow design. A defined term therefore includes reasonable successor, replacement, renamed, regrouped, or technically modified versions of the same operational concept unless these Terms expressly say otherwise.

"Customer" means the person or organization that enters into these Terms or on whose behalf the Service is accessed or used. In most organization-governed use, the Organization controlling the relevant Workspace is the Customer for that Workspace and for the acts and omissions of the Users it authorizes, invites, manages, supervises, or knowingly permits to use the Service through that Workspace.

"Organization" means any company, employer, business, nonprofit, educational institution, governmental body, team, fund, association, partnership, sole proprietorship, or other entity or organized group that creates, sponsors, controls, administers, or uses a Workspace, or on whose behalf Users access or use the Service.

"User" means any individual who accesses or uses any part of the Service, whether as an Admin, a Member, a support contact, an invited person, a public-surface visitor, or another person interacting with the Service in an individual capacity. A User may act only for themselves, only for an Organization, or in both an individual and representative capacity depending on the circumstances.

"Admin" means a User with elevated permissions or authority inside a Workspace or related Service surface, including authority to manage members, invitations, settings, review visibility, workflow controls, report access, reimbursement-related actions, or other Organization-governed administrative functions. The existence of Admin functionality does not itself validate the Admin's underlying real-world authority.

"Member" means a User with non-admin or more limited Workspace access, including a User who uploads or reviews Receipts, participates in reimbursement workflows, accesses Payment History, manages a Payout Method, views Reports, or otherwise uses the Service within an Organization-controlled role that is narrower than Admin authority.

"Workspace" means the Organization-managed account environment, tenant space, or related Service context through which Users, settings, Receipts, reimbursement records, payout-related records, Reports, verification-linked artifacts, and associated permissions or histories are created, displayed, routed, preserved, or managed. A Workspace remains part of the Service even if some related artifacts can later be viewed outside ordinary authenticated Workspace use.

"Service" means GeriPay's websites, hosted application surfaces, onboarding and invitation flows, member and admin tools, Workspace functionality, upload and storage flows, SmartScan and related extraction features, reimbursement-request workflows, payout-method and Payment History features, report and export generation, verification-linked features, support and troubleshooting channels, legal-acceptance and audit-evidence flows, monitoring and security features, Provider-supported infrastructure, and related records, metadata, logs, and successor functions described or contemplated by these Terms.

"Receipt" means a source image, file, document, draft, saved record, or related Service-side record representing a receipt, expense-supporting record, transaction-supporting record, or similar submission, together with associated extracted fields, review edits, evidence, statuses, and linked artifacts as context requires. Depending on context, "Receipt" may refer to the underlying source material, the Service-side record built from it, or both.

"SmartScan" means GeriPay's OCR-assisted, AI-assisted, model-assisted, rules-based, or otherwise automated or semi-automated receipt-processing, extraction, structuring, review-assistance, and data-normalization functionality, including associated preprocessing, evidence capture, confidence or review signals, and successor tools. SmartScan is a Service feature, not a promise of correctness, completeness, or authenticity.

"Reimbursement Request" means any Service-side request, submission, bundle, workflow object, or related record set through which one or more Receipts or expense-related entries are proposed, routed, reviewed, approved, denied, disputed, canceled, paid, retried, corrected, or otherwise processed in a reimbursement-adjacent workflow.

"Payout Method" means any stored, submitted, displayed, or referenced destination detail, payment-destination profile, bank-account-related record, routing detail, payout instrument detail, or similar payment-adjacent instruction that may be used in connection with a reimbursement or payout-related workflow inside the Service.

"Payment History" means the Service-presented chronology of payout-related records, statuses, attempts, updates, corrections, failures, retries, returns, reversals, Provider messages, and related events as they become visible within the Service. Payment History is an operational record set, not a bank statement, settlement ledger, or independent final proof of receipt.

"Report" means any summary, export, packet, PDF, file, generated record set, or similar output produced through the Service for review, sharing, preservation, verification, or related administrative use. A Report may exist in draft, generated, stored, shared, revised, archived, or verification-linked form.

"Verified PDF" means a PDF output generated through the Service that GeriPay associates with a Verification Code, a verification legend, a verification-linked record, a Public Verification Page, or a similar outward-facing validation mechanism internal to the Service. A Verified PDF is not, by reason of that label alone, an independent certification, attestation, or guarantee by GeriPay of the underlying facts.

"Verification Code" means any code, token, identifier, or comparable verification-linked reference generated, displayed, stored, or used by the Service to help retrieve, present, compare, or validate a Report, Verified PDF, or related outward-facing artifact within GeriPay's own system.

"Public Verification Page" means any public or semi-public page, view, endpoint, preview surface, or other outward-facing Service mechanism through which GeriPay may present limited information about a Verification Code, Report, Verified PDF, or related verification-linked artifact to a person outside ordinary authenticated Workspace use.

"Customer Data" means the data, content, records, instructions, uploads, corrections, approvals, destination details, comments, report parameters, identity information, and other information submitted to, entered into, uploaded to, or otherwise provided to the Service by or on behalf of a Customer or its Users, including customer-originated source materials and customer-originated field values. Customer Data does not include the Service itself, GeriPay's underlying software or design assets, generalized know-how, de-identified or aggregated operational information, or other Service Materials except to the extent Customer Data is embedded within or displayed through those materials.

"Service Materials" means the Service itself and GeriPay-owned or GeriPay-controlled software, interfaces, screen designs, prompts, templates, taxonomies, workflows, documentation, methodologies, internal tools, internal review mechanisms, security tooling, de-identified or aggregated operational information, and other materials or technical artifacts owned or controlled by GeriPay apart from Customer Data.

"Providers" means third-party hosting, storage, database, communications, delivery, AI, OCR, security, analytics, monitoring, support, payout-adjacent, verification-support, or other vendors, subprocessors, contractors, or infrastructure partners that GeriPay may use to deliver, support, secure, analyze, operate, or improve the Service.

The phrase "legal-acceptance evidence" means the electronic records GeriPay may preserve regarding presentation of these Terms or related notices, clickthrough or typed-name acceptance events, and, where available and depending on the acceptance flow and system state, timestamps, archived versions, session or browser context, delivery records, confirmation records, and similar evidence of assent, notice, delivery, chronology, or later interpretation. References elsewhere in these Terms to acceptance evidence, electronic acceptance records, or similar concepts should be read consistently with that umbrella phrase unless the surrounding section expressly narrows the point being made.

2.2 Interpretive rules and drafting conventions

References in these Terms to "including," "includes," "for example," "such as," or similar introductory phrases are illustrative and not limiting unless these Terms expressly state otherwise. The singular includes the plural and the plural includes the singular where context permits. References to one gender include all genders, and references to a person or entity include individuals, organizations, successors, assigns, representatives, and permitted delegates as context requires.

Headings, section titles, subsection titles, labels, examples, and internal organizational structure are provided for convenience and readability only. They help locate concepts, but they do not narrow or expand the substantive meaning of the surrounding text unless the operative language of the section clearly does so. If a heading appears shorter or simpler than the surrounding clauses, the surrounding clauses control.

Operational labels, interface text, status badges, menu names, export titles, verification legends, support shorthand, and similar product-facing or user-facing labels are descriptive shorthand and not independent legal definitions unless these Terms expressly say otherwise. A visible label such as saved, pending, approved, paid, verified, failed, active, inactive, corrected, retried, disputed, canceled, or similar wording does not by itself create a warranty, certification, legal conclusion, or binding factual determination beyond what the surrounding provisions of these Terms actually provide.

These Terms should also be read pragmatically in light of the Service's evolving product structure. If a defined concept appears later in lowercase rather than with defined-term capitalization, or appears through a close grammatical variant, the later reference may still carry the same defined meaning where the context clearly indicates the Service-specific concept rather than a purely generic use of the same word. This rule is intended to avoid artificial ambiguity caused by interface-style wording or ordinary sentence flow, not to erase genuine differences in meaning where the context makes those differences important.

References to time, sequence, submission, approval, failure, delivery, deletion, visibility, restoration, preservation, synchronization, or other workflow states describe how records or events may appear within the Service or related Provider-supported systems. They should not be read as promises that every real-world event occurs at the exact same moment the Service records, displays, or labels it.

2.3 Cross-document terminology alignment

These Terms and the Privacy Policy are designed to work together, but they do not perform the same function and should not be forced into identical drafting patterns where doing so would create distortion. These Terms govern access, use restrictions, authority, role disclaimers, risk allocation, investigation rights, suspension rights, disclaimers, liability allocation, indemnity, and dispute structure. The Privacy Policy governs disclosure about information handling, processing roles, data categories, retention, Providers, incidents, rights, and related privacy matters.

Because the two documents do different jobs, the same operational subject matter may be described through different but compatible terminology. For example, these Terms may refer to Customer Data, Service Materials, Workspace authority, public or semi-public verification surfaces, or customer-side responsibility, meaning responsibility allocated to the Customer and its authorized Users acting through the Workspace, while the Privacy Policy may refer to organization-directed processing, GeriPay-controlled processing, data categories, disclosure recipients, or rights-routing limitations. Those drafting differences do not by themselves create a conflict. They reflect different legal purposes applied to the same product environment.

If the same artifact, workflow, or record appears in both documents, the Terms-side description should be read primarily for responsibility allocation, anti-reliance, and enforcement consequences, while the Privacy-side description should be read primarily for disclosure and data-handling transparency. If a direct conflict exists, Sections 1.6 and 20 of these Terms govern how the conflict should be resolved. Informal attempts to use Privacy-side disclosure language to narrow a Terms-side disclaimer, or to use a Terms-side allocation clause to erase a Privacy-side disclosure obligation, should be rejected unless the text expressly says that result is intended.

Nothing in this Section requires GeriPay to use identical capitalization, identical clause ordering, or identical sentence structure across all legal documents. What matters is functional consistency, not cosmetic uniformity. Terms used in one document should therefore be interpreted in a way that keeps the document set coherent while preserving the narrower job each document is intended to perform.

2.4 Public-surface and private-surface distinctions

The Service includes both private and outward-facing layers, and those layers must not be collapsed into each other. Private layers include authenticated Workspace views, admin and member interfaces, settings surfaces, internal review tools, support-facing or investigation-facing records, and other access-limited environments through which a Customer or GeriPay may view, manage, preserve, or analyze records that are not intended for general public access. A record may remain private even if multiple internal users, support personnel, or Providers can access it for legitimate operational reasons.

The Service may also include public or semi-public verification surfaces, including a Public Verification Page, a verification-enabled preview, a shared Report surface, or another outward-facing mechanism associated with a Verification Code or similar identifier. Those surfaces may expose limited information to outsiders, code holders, recipients, counterparties, auditors, or other viewers outside ordinary authenticated Workspace use. But the existence of such a surface does not mean that all underlying Customer Data, all surrounding workflow history, all internal notes, all related Receipts, or all associated records have become public.

A public or semi-public verification surface is therefore a limited presentation layer, not a waiver of privacy, confidentiality, security, evidentiary, or allocation protections that otherwise apply under these Terms or the Privacy Policy. GeriPay may decide what information to present, suppress, gate, mask, limit, archive, rate limit, or remove from those outward-facing surfaces, and may preserve materially broader private records behind the scenes than what an outsider is permitted to see.

Likewise, a person's ability to view a public or semi-public surface does not automatically make that person a Customer, an authorized Workspace User, an intended beneficiary of all Service functionality, or a person entitled to rely on all private records associated with the underlying artifact. These Terms may still bind that person to the extent the relevant surface presents or incorporates them, but the scope of access and the scope of reliance remain limited by the nature of the surface being used.

2.5 Temporal and version-aware concepts

The Service may preserve multiple versions, timestamps, states, revisions, exports, archived copies, superseded records, logs, Provider messages, corrections, acceptance records, and historical snapshots relating to the same underlying subject matter. The latest visible record is not always the only relevant record, and a later correction, later export, later status, or later interface view does not automatically erase the significance of earlier preserved records for audit, support, fraud review, dispute defense, legal process, or chronology reconstruction.

Different timestamps may reflect different things, including upload time, conversion time, extraction time, user-review time, approval time, export time, verification time, Provider-reported event time, storage time, display time, archival time, or evidence-preservation time. Those timestamps may not all match each other, and they may reflect the timing of when GeriPay or a Provider recorded or received an event rather than the exact moment a real-world event occurred outside the Service.

References in these Terms to deleted, removed, hidden, unavailable, expired, superseded, replaced, corrected, deactivated, revoked, archived, or preserved records should be read with that layered chronology in mind. A record may stop being visible in one surface while still existing in a backup, archive, log, legal-hold set, investigation file, support record, or preserved evidence package. Similarly, a revised Report, a regenerated Verified PDF, or an updated Verification Code presentation may coexist with older preserved versions without making those older versions irrelevant.

This same approach applies to contractual versions. The version of these Terms or another binding policy presented at a relevant acceptance event may remain important for that event even after a later version becomes the current public version. Later amendments may govern later access or later conduct, but they do not necessarily rewrite the historical meaning of earlier preserved legal-acceptance evidence or earlier Service records.

Section 3. Service Scope and Product Surfaces

3.1 Covered product surfaces

The Service includes, without limitation, current and future surfaces through which GeriPay offers account access, Workspace management, record capture, extraction, workflow routing, Report generation, verification, support, monitoring, evidence preservation, and related functionality. Covered surfaces include websites, hosted application pages, member and admin interfaces, signup and invite-completion flows, settings and security flows, receipt-upload experiences, storage-backed preview or retrieval paths, SmartScan review tools, reimbursement-request tools, payout-method tools, Payment History displays, Report-generation tools, Verification Code flows, the Public Verification Page and other public or semi-public verification surfaces, file preview or delivery surfaces, support channels, and provider-supported operational layers used to deliver those features.

The Service also includes generated records, derived records, metadata, audit trails, status histories, logs, and other technical or operational artifacts created in the ordinary course of operating those surfaces, even if users do not directly view every component. A feature does not fall outside these Terms merely because it is admin-facing, member-facing, organization-facing, public-facing, provider-supported, renamed, regrouped, updated, or delivered through a successor workflow.

3.2 Service capabilities and non-capabilities

GeriPay may receive, ingest, convert, store, organize, display, compare, route, structure, summarize, track, generate, export, preserve, and otherwise technically process records and record-adjacent information. The Service may create draft records, saved records, structured fields, review histories, reimbursement workflow states, payout-related records, payment-history entries, Reports, Verified PDFs, verification-linked artifacts, legal-acceptance evidence, logs, and similar operational outputs.

Those capabilities do not mean GeriPay independently determines the truth, completeness, legality, business purpose, policy compliance, reimbursement entitlement, tax treatment, accounting treatment, employment treatment, payee identity, destination ownership, bank acceptance, or final settlement status of the matters reflected in those records. The Service can support customer review, organization workflows, and downstream coordination, but it does not replace the customer-side or downstream decision-making that must occur outside the software layer.

3.3 Variation by organization, role, feature set, and geography

Feature availability may vary by role, organization configuration, internal permissions, geography, applicable law, provider availability, technical environment, beta or limited-release status, fraud or security review, and other operational considerations. Not every organization will use the same workflow, not every user will have access to the same tools, and not every feature will remain available in the same form over time.

GeriPay may set, change, or enforce feature gates, role limits, eligibility requirements, operational conditions, or access restrictions without creating an obligation to make every surface available to every user or organization. The existence of a feature in one context does not create an entitlement to that feature in another context.

3.4 Public verification, semi-public artifacts, and outward-facing surfaces

Some Service outputs may be accessible outside ordinary authenticated Workspace use, including through Verification Codes, shared Reports, the Public Verification Page, preview surfaces, or other code-enabled or outward-facing mechanisms. Those surfaces remain part of the Service and remain subject to these Terms to the extent applicable, including where the relevant surface presents or incorporates them, even though the underlying Workspace may remain private and organization-managed.

The existence of a public or semi-public surface does not mean that all underlying records are public, and it does not create a certification, endorsement, attestation, or independent validation regime by GeriPay. Subject to then-current product design, technical constraints, provider realities, and legal considerations, GeriPay may log, rate limit, gate, alter, suspend, or remove outward-facing surfaces at any time for security, operational, legal, product, or abuse-prevention reasons.

3.5 Experimental, evolving, and local-only components

The Service may include, use, depend on, or be supported by evolving, testing, beta, preview, limited-release, maintenance, diagnostic, support-only, internal, benchmark, or local-only components. Unless GeriPay expressly makes a feature generally available as part of the Service, no user or organization has a right to demand access to internal or limited-release tooling, or to treat the existence of such tooling as a contractual promise about customer-facing functionality.

Likewise, old labels, deprecated flows, internal names, temporary screens, support-only workarounds, benchmark utilities, or prior versions of a workflow do not create a continuing right to identical future treatment. The Service is expected to evolve, and these Terms are written to preserve that flexibility.

3.6 Service modification, suspension, and discontinuation rights

GeriPay may at any time patch, update, migrate, redesign, regroup, rename, narrow, pause, replace, or discontinue any part of the Service, including workflows, models, providers, file-handling methods, public verification behavior, export formats, and status or presentation logic. GeriPay may also impose limits, conditions, sequencing changes, re-authentication requirements, or restricted access states where it believes that doing so is appropriate for security, fraud prevention, provider management, legal compliance, platform integrity, public-surface protection, or product development.

This Section 3 is descriptive and perimeter-setting only. It defines what kinds of surfaces and functions fall within the Service. It does not itself create a warranty that any covered surface will remain available, unchanged, accurate, continuous, error-free, certification-grade, or suitable for any particular use, and it does not expand GeriPay's role beyond the software and technical functions expressly described in these Terms.

Section 4. What GeriPay Is Not

4.1 No bank, money transmitter, or stored-value provider

GeriPay provides software and related technical services. Even when the Service stores, displays, routes, or generates information about reimbursements, payout methods, payment history, reports, verification artifacts, or other financial-adjacent matters, GeriPay is not and does not hold itself out as a bank, depository institution, money transmitter, money services business, payment processor, payment service provider, payment facilitator, merchant acquirer, acquiring service, clearing service, settlement service, payment initiation service, payment execution service, funds-transfer service, stored-value service, wallet provider, or cash-management service.

No license, registration, authorization, or regulated undertaking of that kind should be inferred from the existence of reimbursement workflows, payout-method records, payment-history statuses, Verified PDFs, the Public Verification Page, other public or semi-public verification surfaces, or any other Service feature. The Service may record, display, or support information that in other contexts could relate to regulated financial activity, but GeriPay does not thereby become the regulated financial actor associated with that subject matter.

4.2 No lender, creditor, guarantor, or source of reimbursement obligation

GeriPay is not a lender, creditor, credit provider, underwriter, loan servicer, debt administrator, insurer, surety, guarantor, or source of reimbursement funding. The Service does not extend credit, promise reimbursement, guarantee repayment, underwrite any request, or assume any obligation to fund, advance, reimburse, or make good on any amount.

A status such as submitted, pending, approved, paid, failed, retried, reversed, disputed, canceled, or any similar workflow or payment-adjacent label reflects only the state of records, instructions, or events as represented within the Service. No such label means that GeriPay has committed its own funds, assumed a debt obligation, guaranteed an organization's decision, guaranteed an outside provider's performance, or assumed responsibility for the final timing, amount, destination, or completion of any transfer or reimbursement outcome.

4.3 No custodian, trustee, fiduciary, escrow agent, or safekeeping institution

GeriPay does not hold, receive for safekeeping, possess, control, or disburse customer or user funds, and does not control bank accounts, downstream payout destinations, or financial accounts merely because destination or payment-adjacent information appears in the Service. GeriPay is not a custodian, escrow agent, settlement agent, paying agent, trustee, safekeeping institution, transfer agent, or similar holder or controller of value or legal rights.

Use of the Service also does not create a fiduciary, trustee, agency, representative, best-interest, attorney-in-fact, or other special trust-based relationship between GeriPay and any user, organization, payee, beneficiary, counterparty, or outsider, except to the limited extent non-waivable law expressly requires otherwise. GeriPay does not undertake to act on behalf of users in a representative legal capacity, to safeguard assets for them, or to optimize outcomes in their best financial, legal, operational, or policy interests.

4.4 No payroll, tax, accounting, bookkeeping, audit, or legal-advice provider

GeriPay is not a payroll provider, payroll processor, payroll administrator, employer-of-record service, benefits administrator, human-resources administrator, worker-classification service, tax advisor, tax preparer, tax filing service, accountant, bookkeeper, accounting service provider, auditor, assurance provider, attestation provider, financial-statement preparer, law firm, legal advisor, compliance advisor, regulatory compliance service, sanctions compliance service, AML service, KYC service, identity-verification service, or records-retention compliance guarantor.

The Service does not determine wage treatment, worker classification, benefit eligibility, tax treatment, accounting treatment, audit sufficiency, financial-statement treatment, legal sufficiency, regulatory sufficiency, or internal policy sufficiency. SmartScan outputs, Report exports, reimbursement histories, Payment History displays, and legal-acceptance evidence may be useful as operational records, but they are not professional advice, professional opinions, compliance clearance, or a substitute for independent review by qualified advisors and decision-makers.

4.5 No employer, plan sponsor, plan administrator, claims adjudicator, or benefits administrator

GeriPay is not the employer of any user, the sponsor or administrator of any reimbursement program, the claims adjudicator for any expense or reimbursement request, the internal approval authority for any organization, or the author or enforcer of any organization's expense, reimbursement, payout, payroll, tax, legal, accounting, or recordkeeping policy. GeriPay does not decide who should be paid, what amount is owed, what documentation is sufficient, what internal exceptions are permissible, or what internal controls an organization must follow.

Organizations and their authorized personnel remain responsible for setting policies, assigning roles, reviewing submissions, validating beneficiaries and payout destinations, approving or denying requests, handling exceptions and disputes, maintaining segregation of duties, supervising personnel, and deciding how to rely on records or reports. The Service may route, store, display, or organize those processes, but it does not make the underlying organizational judgment on GeriPay's behalf.

4.6 No certification, attestation, authenticity, or fraud-screening authority

GeriPay does not certify, attest to, notarize, authenticate, or independently validate the authenticity, legality, completeness, correctness, merchant identity, payee identity, beneficiary ownership, reimbursement eligibility, business purpose, policy compliance, transaction legitimacy, or fraud-free status of source materials, derived records, or outputs in the Service. GeriPay is not a document-authentication service, receipt-authenticity certification service, merchant-verification service, payee-verification service, beneficiary-verification service, record-authenticity guarantor, record-completeness guarantor, data-accuracy guarantor, fraud-detection guarantor, or independent verification authority.

Accordingly, SmartScan results, review states, reimbursement statuses, Payment History entries, Reports, exports, Verified PDFs, Verification Codes, the Public Verification Page, other public or semi-public verification surfaces, and legal-acceptance evidence may have operational, evidentiary, or administrative value, but none of them by itself is a representation by GeriPay that the underlying facts are true, complete, lawful, authorized, genuine, or free from manipulation, mistake, abuse, or fraud. The presence of a verification feature means only that GeriPay may link or present certain records within its own system, not that GeriPay has performed an external certification-grade review of the underlying subject matter.

4.7 No sanctions, AML, anti-bribery, or regulatory clearance authority

GeriPay is not a sanctions screener, AML monitor, anti-bribery or anti-corruption certifier, beneficial-ownership verifier, licensing or regulatory-clearance authority, or other regulated gatekeeper merely because the Service may preserve evidence, flag suspicious activity, restrict access, or support investigations. GeriPay does not undertake to clear users, counterparties, beneficiaries, transactions, organizations, or uploaded materials for legal, regulatory, sanctions, AML, anti-bribery, employment, tax, accounting, reimbursement, or other compliance purposes.

If you or your organization need a licensed, regulated, certified, or professionally qualified provider for any of those functions, you are responsible for obtaining and relying on that provider independently of GeriPay. These role disclaimers are structural and must be read together with the reimbursement, payout, provider, warranty, liability, indemnity, and dispute sections of these Terms. No feature name, workflow label, report, verification page, support step, monitoring action, or provider relationship expands GeriPay's role beyond the software and related technical functions expressly undertaken in these Terms.

Section 5. Eligibility, Authority, and Organization Binding

5.1 Eligibility to use the Service

You may use the Service only if you have the legal capacity to enter into a binding agreement under applicable law and only if your access and use are for legitimate business, operational, administrative, reimbursement-management, reporting, recordkeeping, or related organizational purposes. The Service is not offered as a general-purpose consumer convenience tool, a sham front for unlawful conduct, or a neutral platform for any use a person happens to attempt. Use that is deceptive, evasive, unauthorized, materially misleading, or inconsistent with these Terms is outside the permitted eligibility perimeter from the start, even if a login, invite, or workflow step can technically be reached.

Eligibility is an ongoing condition of use, not a one-time status determined only at signup. A person or organization may appear to satisfy minimum formal access conditions and still be denied, delayed, conditioned, narrowed, or removed from access if GeriPay reasonably concludes that the proposed use, the user, the organization, the authority chain, the risk profile, or the surrounding circumstances are not appropriate for the Service. Nothing in these Terms requires GeriPay to keep access open merely because an account was created, an invite was sent, or a technical onboarding step was completed.

5.2 Authority to bind an organization

If you create a workspace, complete signup for an organization-facing account, accept an invitation into an organization-controlled workspace, act as an administrator, or otherwise use the Service on behalf of an organization, you represent and warrant that you are duly authorized to do so and that you may bind yourself and, where applicable, that organization to these Terms. Where the Service is used on behalf of an organization, that organization is the Customer for the relevant workspace and is responsible for the acts and omissions of the people it authorizes, invites, manages, supervises, or permits to use that workspace or its related features.

GeriPay may rely on apparent authority reflected in submitted account information, invite flow completion, administrator designations, role assignments, organization email domains, workspace state, titles, communications, and other signals reasonably available through the Service unless GeriPay has actual contrary notice. GeriPay does not undertake to verify every board resolution, employment record, delegation chain, finance-policy approval, procurement signoff, or other internal authorization document before permitting access or honoring role-based activity. If a person claims authority they do not actually have, accepts on behalf of an organization without authorization, uses a sham or misidentified organization, or causes GeriPay to rely on false authority signals, GeriPay may refuse or restrict access, preserve evidence, investigate, suspend or terminate the affected access, and treat the person making that representation as personally responsible for resulting misuse, losses, claims, or disputes to the fullest extent permitted by law.

5.3 Admin authority, delegated authority, and role boundaries

Administrative access is a customer-side control function with real operational consequences. Administrators and similarly privileged users may be able to invite or remove users, assign or adjust roles, change visibility boundaries, influence who can review or act on reimbursement-related records, manage access to reports and related materials, and otherwise shape how a workspace functions. The organization, not GeriPay, is responsible for deciding who should receive that authority, what internal approvals are required before granting it, how such authority should be supervised, and when it should be narrowed, revoked, or transferred.

The existence of admin-facing controls does not mean GeriPay is designing or validating the customer's internal governance model. GeriPay provides the technical mechanics through which authority may be expressed inside the Service, but the organization bears the consequences of weak delegation, overbroad permissions, stale admin privileges, poor segregation of duties, unreviewed overrides, informal approval chains, or the assumption that visible product access equals proper internal authority. Users with limited roles must act only within those roles, and no interface element, status, or workflow path should be read to create broader authority than the organization has actually granted.

5.4 Accuracy of identity, contact, and role information

All names, email addresses, titles, affiliation details, organization identifiers, role descriptions, and comparable onboarding, account, or access-related information you provide to GeriPay must be truthful, current, complete, and authorized for the use being made of the Service. You may not create or use synthetic identities, aliases intended to evade restrictions, sham departments, sham organizations, false contact points, or impersonation-based access. You may not use another person's credentials, inbox, recovery channel, or identity details without authorization, and you may not allow a misnamed, departed, unauthorized, or otherwise improper person to continue appearing inside the Service as if they were still the proper user or representative.

GeriPay may rely on the identity and role information supplied through the Service unless it has actual contrary notice. GeriPay is not required to detect every false identity, internal impersonation scheme, stale personnel record, misaddressed invite, forwarded invitation, shared-inbox error, compromised inbox, alias account, or internal directory mistake before activity occurs. The organization and its users bear responsibility for keeping access-related information accurate over time and for the consequences of stale, misleading, or unauthorized identity and affiliation data reflected in the workspace.

5.5 Continuing authority and loss of authority

The representations described in this Section must remain true throughout use of the Service. A person who loses the relevant authority, affiliation, eligibility, capacity, or internal approval necessary to access or act within the Service must stop doing so immediately. This includes situations involving role change, employment termination, contractor disengagement, loss of admin status, revocation of delegated authority, sanctions or legal-restriction changes, contested authority, or any other circumstance that makes continued access improper. Organizations must promptly update or revoke access when a person should no longer be using the relevant workspace or feature set.

Continued use after authority is lost or materially disputed may be treated as unauthorized access or misuse even if an account, session, or invite technically remains active. Deactivation, removal, suspension, or restriction does not retroactively invalidate prior acceptance of these Terms, prior workspace activity, prior submissions, prior approvals, or other historical records already created in the Service. If access is later restored, GeriPay may require renewed acceptance, updated information, added verification, or other new conditions before continued use is permitted.

5.6 Restricted users and high-risk use contexts

You may not use the Service in a manner that is prohibited by law or that would reasonably expose GeriPay or its providers to sanctions, embargo, fraud, abuse, security, regulatory, operational, reputational, integrity, or comparable risk. GeriPay may refuse, delay, condition, narrow, challenge, restrict, suspend, or terminate access where it reasonably believes a person, organization, geography, use case, transaction pattern, authority chain, or surrounding circumstance presents elevated risk or is incompatible with the Service. GeriPay may request supplemental information, documentation, confirmations, or other verification before allowing onboarding or continued use, and GeriPay may act even when the available information is incomplete or still developing.

Nothing in this Section means GeriPay is undertaking to serve as a sanctions screener, compliance monitor, AML analyst, or comprehensive gatekeeper for the customer. GeriPay is reserving protective discretion, not promising exhaustive detection or exhaustive explanation. To the fullest extent permitted by law, GeriPay need not disclose every reason, signal, or provider-side input that contributed to a refusal, delay, or restriction decision.

Section 6. Registration, Invitations, and Account Lifecycle Entry Points

6.1 Direct signup and initial organization creation

Direct signup is one permitted pathway into the Service, including the creation of a new organization-facing account and the initial workspace through which later users may be invited or managed. A person completing that flow represents that the submitted user and organization information is accurate, that the workspace is being created for a legitimate and authorized purpose, and that the person taking that step is entitled to act as the initial organization-side administrator or other authorized representative. Even where signup succeeds technically, signup alone does not prove the continuing legitimacy of the organization, the continuing accuracy of the submitted information, the sufficiency of the internal approval chain, or the permanent right of any person to retain access.

GeriPay may revisit, question, condition, or correct the assumptions associated with initial signup at any time, including by seeking additional information, delaying activation, limiting feature availability, narrowing permissions, or later challenging the role initially associated with a user. The fact that a person became the first visible admin or first visible workspace creator does not mean GeriPay certified that person's authority, employment status, internal title, or long-term entitlement to control the workspace.

6.2 Invitation-based onboarding and invite acceptance

Invitation-based onboarding is another permitted pathway into the Service. Invitations may be issued, revoked, replaced, invalidated, or allowed to expire, and GeriPay may change the mechanics of invitation delivery or acceptance over time. An invitation may be accepted only by the intended, authorized recipient for the intended organization relationship. You may not accept an invitation sent to another person, accept a forwarded or intercepted invitation without authorization, or rely on the mere existence of an invitation as proof that the recipient remains the correct person or remains currently authorized by the organization.

The organization is responsible for invite hygiene, including selecting the proper recipient, using appropriate delivery channels, avoiding stale or shared inboxes where inappropriate, and revoking or replacing invitations when circumstances change. GeriPay is not responsible for losses caused by misaddressed invites, forwarded email, shared inbox practices, compromised inboxes, delayed revocation, stale authority, or the organization's failure to control who receives and uses invitation-based access.

6.3 Verification steps, contact confirmation, and account activation

GeriPay may require one or more verification, confirmation, or activation steps before permitting or continuing access, including email verification, code entry, invite-linked confirmation, or comparable technical or procedural steps. Those steps help establish that a communication channel or account flow was completed, but they do not by themselves prove legal identity, employment status, organization legitimacy, continuing authority, internal policy compliance, or the absence of fraud, coercion, compromise, or impersonation. No user or organization may overread a successful verification step as a warranty by GeriPay that the verified person is the correct person for all purposes or that access should never later be challenged.

GeriPay may require additional or repeated verification at any time, including after suspicious activity, role changes, access disputes, security events, provider-side concerns, policy updates, or legal or operational review. GeriPay may also treat failed, incomplete, or inconsistent verification signals as grounds to delay or restrict access without promising that every review will be completed on any particular timetable.

6.4 Account creation discretion and incomplete onboarding

GeriPay may refuse, pause, delay, challenge, or stop onboarding for any account, workspace, or invite flow where additional information is needed, where risk appears elevated, where identity or authority is uncertain, where provider or system constraints interfere, or where GeriPay otherwise reasonably concludes that immediate activation is not appropriate. GeriPay may request documentation, confirmations, supplemental statements, or corrective action before allowing onboarding to proceed, and GeriPay is not required to disclose every internal or external reason for such a decision to the fullest extent permitted by law.

Accounts may exist in incomplete, partial, pending, unverified, invited, revoked, expired, restricted, challenged, or otherwise limited states. Such states are part of the Service's operational reality and do not create a vested right to full activation, feature parity, or uninterrupted access. GeriPay may allow some preparatory steps to occur before full access is granted, or may require later steps before previously visible features remain available.

6.5 Credential setup, recovery entry points, and lifecycle transitions

Registration and onboarding are only part of the broader account lifecycle. Password setup, password reset, email-change flows, invite acceptance updates, recovery steps, and other access-restoration or access-transition mechanics are convenience and security features within the Service, not unconditional entitlements. GeriPay may add, remove, redesign, delay, or condition those mechanics over time, may require extra verification before honoring them, and may refuse to complete a recovery or change request where compromise, dispute, fraud risk, or authority uncertainty appears present.

No recovery or update path should be understood to mean that GeriPay can always restore the correct person to the correct account immediately, can always detect misuse before damage occurs, or can always reverse every consequence of earlier access. The organization and the user remain responsible for protecting the contact channels and internal approval processes that make these lifecycle transitions trustworthy.

6.6 Records created during onboarding

GeriPay may create, maintain, copy, preserve, and later rely on records generated during onboarding and access-entry flows, including invite records, verification records, timestamps, archived versions of presented legal text, account-state transitions, role-assignment history, request and response metadata, IP-related information, browser and device context, client identifiers, and comparable technical or operational evidence. Those records may be retained even if the related invite expires, the account is never fully activated, the user later loses access, or the organization later disputes the underlying authority chain.

These onboarding records are part of the Service's evidentiary and operational infrastructure. They may be used for support, security, fraud review, dispute resolution, audit support, legal process, or internal Service defense, and they do not lose relevance merely because the visible onboarding flow has concluded. Nothing in this subsection promises perfect completeness or perfect reconstruction of every historical screen state, but it does preserve GeriPay's right to maintain and rely on a broad package of onboarding evidence and related metadata.

Section 7. Electronic Records, Electronic Signatures, and Legal Acceptance Evidence

7.1 Consent to electronic records and communications

To the fullest extent permitted by law, you consent to receive, review, sign, accept, store, and retain records, notices, disclosures, agreements, updates, confirmations, and other communications from GeriPay in electronic form. Electronic delivery may occur through email, account-level notices, in-product presentation, logged acceptance flows, downloadable copies, archived records, or other electronic channels GeriPay reasonably uses. GeriPay does not undertake to provide paper copies by default, and the Service is designed around electronic presentation and electronic acceptance rather than paper-first contracting.

You are responsible for maintaining current contact information, reliable access to your inboxes and devices, and a practical ability to review and retain electronic records if you wish to keep copies for your own files. Failure to maintain those channels does not shift responsibility to GeriPay if a notice or legal record was made available through the electronic methods permitted by these Terms. If you cannot or will not operate through the electronic-record framework used by the Service, GeriPay may refuse onboarding, re-consent, restoration, or continued use to the fullest extent permitted by law.

7.2 Typed-name signatures, click acceptance, and comparable digital assent

Typing a name, clicking an acceptance button, checking an acknowledgment box, completing an invite-acceptance flow, completing a re-consent flow, or taking another clearly designated digital action within GeriPay's legal-acceptance process may constitute an electronic signature, an electronic acknowledgment, and a legally significant manifestation of assent to the extent permitted by law. Where GeriPay presents a legal record and then requires a signature-like act to proceed, that act is intended to be meaningful. It is not merely decorative, informational, or cosmetic.

At the same time, GeriPay is not required to prove assent through one isolated data field alone. GeriPay may rely on the full acceptance ceremony, including the typed-name step, the surrounding page or flow state, the acceptance button or confirmation event, the related account or invite context, the accepted version records, and the technical and chronological evidence preserved with that event. If a user later disputes memory, intent, or authorship, GeriPay may still rely on the total evidentiary package associated with the digital acceptance event.

7.3 Acceptance-event metadata and contextual evidence

GeriPay may create, retain, correlate, and later rely on metadata and supporting records associated with legal acceptance events, including, where available and depending on the acceptance flow and system state, timestamps, chronology, sequence records, scroll-completion or review-completion records, page-state or route-state records, document and version identifiers, account and membership linkage, client identifiers, session-related context, IP-related information, browser and device context, hashes, archived copies, duplicate logs, and other technical or operational records that reasonably bear on the acceptance event. Those records may be preserved even if the user later loses access, the workspace later changes, or the visible flow is redesigned.

The purpose of this evidentiary package is not to claim that every data point is infallible or that every later factual dispute disappears. The purpose is to preserve a structured, multi-layered record of how assent occurred, what was presented, in what order the relevant steps occurred, and what technical context existed at the time. Missing one category of metadata does not invalidate every other part of the record, and GeriPay may rely on the categories of evidence that remain available.

7.4 Version-aware assent and superseded terms records

GeriPay may preserve which version of these Terms, which version of the Privacy Policy, and which other related legal records were presented and accepted at a given time, including effective-date references, version labels, content identifiers, archived copies, related hashes, and later re-acceptance or update events. A later revision does not automatically erase the earlier historical record. Superseded legal text may remain important in determining what controlled at the time of signup, invite acceptance, feature activation, re-consent, suspension, dispute, or other relevant events.

If GeriPay later updates its legal package, GeriPay may require fresh assent, may rely on continuing-use mechanics where permitted by law, may preserve both the prior accepted version and the later version, and may use those layered records to show which document controlled at which time. No user or organization should assume that only the most recent visible version matters for all historical issues. Earlier accepted versions may remain relevant to past conduct, past rights, and past obligations even after later versions are published.

7.5 Reconstructed records, duplicate logs, and retained artifacts

GeriPay may preserve reconstructed records, duplicate records, normalized logs, archived text, system-generated summaries, screenshots, historical copies, integrity markers, and comparable retained artifacts when the exact original display state, every transient UI pixel, or every surrounding technical detail is not preserved indefinitely. The absence of one exact visual state does not mean the acceptance event is unprovable, and the absence of one original delivery artifact does not require GeriPay to disregard the rest of the preserved evidence.

Reconstructed or duplicate records may still be used to show what legal record existed, what version was linked to the acceptance event, what chronology was preserved, and what acceptance act occurred. GeriPay does not promise perfect archival completeness, perfect preservation of every screen transition, or perfect future recreation of every past acceptance flow. It does preserve the right to rely on historically maintained records that reasonably reflect the relevant legal event.

7.6 Admissibility, evidentiary weight, and anti-paper-original arguments

To the fullest extent permitted by law, electronic records, electronic signatures, archived versions, hashes, logs, chronology, metadata, duplicate records, and related technical or operational evidence preserved by GeriPay may be used in support, security reviews, internal investigations, audits, insurance matters, arbitration, court-related proceedings, regulatory inquiries, and other legal or dispute-resolution contexts. GeriPay may submit, describe, authenticate, rely on, or otherwise use those records to establish assent, establish timing, identify the accepted version, rebut denial of assent, or support later enforcement and defense positions.

No user or organization may argue that these Terms are unenforceable merely because the relevant records were electronic, because the signature was typed or click-based rather than handwritten, or because the preserved evidence includes archived, duplicate, reconstructed, or machine-generated records rather than a single paper original. GeriPay does not claim that every electronic record conclusively proves every disputed fact in every case, but it does reject the premise that wet-ink signatures, paper originals, or perfect human recollection are necessary preconditions to enforceability or evidentiary use.

Section 8. Accounts, Credentials, Sessions, and Access Security

8.1 Account credentials and confidentiality duties

You are responsible for maintaining the confidentiality and security of your credentials, authentication secrets, linked email inboxes, recovery channels, and comparable access mechanisms used with the Service. Credentials must be kept strong, confidential, and reasonably protected from reuse, casual disclosure, insecure storage, or unauthorized circulation. You may not share passwords or similar secrets, pool identity-specific credentials across multiple people, or treat login information as an internal convenience tool that can be passed around without consequence. The organization is responsible for enforcing comparable discipline for the personnel and representatives it allows to use the Service.

The Service depends on customer-side access hygiene. GeriPay is not insuring your credentials, inboxes, local devices, or internal distribution practices against compromise. To the fullest extent permitted by law, losses arising from weak credential hygiene, password reuse, careless storage, insecure recovery practices, or internal credential sharing remain on the customer side unless those losses are caused by GeriPay's own breach of a specific duty that cannot be disclaimed under applicable law.

8.2 Sessions, remembered devices, and authenticated state

You are responsible for protecting active sessions, remembered logins, browser persistence, local caches, stored tokens, and other continuity mechanisms that allow the Service to recognize an authenticated user or device. This includes using appropriate care on shared, public, family-accessible, contractor-accessible, kiosk, or otherwise exposed devices and taking reasonable steps to sign out, remove saved access, or secure the environment when continued visibility or use would be inappropriate. Browser persistence, remembered devices, or session continuity features are not representations that the surrounding environment is trustworthy.

If a session remains active on a compromised, shared, or inadequately protected device or browser, the resulting activity may still be attributed to the relevant account or organization unless and until GeriPay receives actual notice requiring protective action or has otherwise already restricted the affected access. GeriPay is not responsible for clipboard exposure, local download exposure, shoulder-surfing, screen-capture risk, browser-sync exposure, or other customer-side consequences of leaving an authenticated environment insufficiently protected.

8.3 Delegated access, shared inboxes, and internal account-sharing practices

If an organization chooses to involve assistants, finance personnel, consultants, accountants, contractors, outside administrators, shared email aliases, or other delegated or representative actors in Service access or workflow execution, that is a customer-side governance choice. The organization is responsible for supervising those people, deciding what they may see or do, ensuring that role assignments remain appropriate, and preventing delegation practices that destroy attribution, weaken auditability, or create misleading authority signals. Weak internal delegation practices do not become GeriPay's responsibility simply because the Service records the resulting activity.

Unless GeriPay expressly authorizes a different model in writing, user accounts are identity-specific and may not be lent, borrowed, pooled, or used as general team logins. You may not use another person's account or allow another person to use your account in a way that obscures who actually acted. The organization bears responsibility for shared inbox habits, informal credential lending, delegated review performed through the wrong identity, and the downstream consequences of treating personalized access as a group utility.

8.4 Notice of compromise and prompt response duties

You must promptly notify GeriPay if you know or reasonably suspect that credentials, sessions, invitation links, email inboxes, recovery channels, devices, browsers, workspace roles, or other access mechanisms associated with the Service have been compromised, misdirected, misused, or exposed to unauthorized persons. Prompt notice is also required when you discover suspicious activity, unauthorized exports, unexpected workflow changes, unexplained role changes, apparent impersonation, suspected social engineering, or any comparable access-integrity issue. Delay in notice may worsen harm and may reduce GeriPay's ability to contain the issue, preserve evidence, or limit downstream effects.

After notice, GeriPay may invalidate sessions, challenge access, require re-verification, freeze affected activity, narrow features, preserve evidence, request explanations or documents, coordinate with providers, or take other emergency protective measures. You and the organization must cooperate in a timely and accurate manner. GeriPay does not guarantee that every compromise can be fully reversed, that every affected record can be restored to a preferred prior state, or that every actor or root cause can be identified immediately.

8.5 Reliance on authenticated actions and records

To the fullest extent permitted by law, GeriPay may rely on instructions, submissions, edits, approvals, exports, report-generation requests, payout-method updates, acceptance events, and other activity associated with valid credentials, active sessions, apparently authorized identities, or apparently authorized workspace roles unless GeriPay has actual contrary knowledge or has already imposed a restriction that should have prevented reliance. The Service is designed to respond to authenticated and role-based signals, and GeriPay is not required to suspend ordinary reliance each time a customer may later claim that an internal actor should not actually have been authorized.

Disputes about whether an employee, contractor, manager, finance lead, departing admin, or other internal actor should have been permitted to act are generally customer-side disputes, not grounds to recharacterize ordinary Service reliance as wrongful by GeriPay. This subsection does not mean GeriPay promises to honor every authenticated act uncritically in every circumstance; it does mean that the baseline operational assumption of the Service is that authenticated and apparently authorized activity may be treated as meaningful unless and until contrary facts require intervention.

8.6 Security-related access restrictions and re-verification rights

GeriPay may at any time challenge, delay, narrow, freeze, re-route, or deny access if it detects suspicious logins, inconsistent authority signals, compromised-device indicators, phishing or abuse signals, provider alerts, legal-risk issues, unusual workflow behavior, or any other circumstance that causes GeriPay reasonably to question whether continued access should proceed without further review. GeriPay may require step-up verification, additional confirmations, new acceptance events, session invalidation, device re-checks, or manual review before restoring or expanding access.

These protective measures may inconvenience users, delay workflows, or interrupt otherwise expected use, and they do not create a warranty that compromise, fraud, account takeover, or internal misuse will be prevented in every case. GeriPay may act conservatively, may act with incomplete information, and may maintain restrictions while facts are still being developed. The existence of security controls does not transfer the customer's own access-security and governance responsibilities to GeriPay.

Section 9. Workspace Governance, Roles, and Internal Access Control

9.1 Workspace ownership and organization control

Organization workspaces are controlled by the organization, not by each individual person who happens to submit, review, edit, or view records inside them. Individual user access is derivative of the organization's authorization decisions and the role state reflected in the Service. The fact that a person uploaded a receipt, reviewed a SmartScan output, submitted a reimbursement request, viewed a payout-related record, or generated or accessed a report does not create a personal ownership right in the workspace environment as against GeriPay. The organization controls who is admitted, what role each person receives, how internal visibility is structured, and what access continues after role or relationship changes.

Loss or narrowing of organization authorization can therefore change what an individual may see or do, even if the broader account or historical identity remains in existence. GeriPay may preserve workspace history and related records while still honoring organization-side control over current access boundaries. This organization-control model is fundamental to the Service and should not be overread as a promise that every user will always retain the same visibility or influence over the same records.

9.2 Admin roles, privileges, and internal control burden

Administrative privileges are significant internal-control powers, not mere convenience settings. Administrators may shape access, visibility, workflow influence, and the practical operation of the workspace. The organization is responsible for deciding who should be an administrator, what training or internal approval that status requires, how administrator authority should be supervised, what actions should be segregated, and how quickly stale or unsafe admin access should be removed. GeriPay does not act as the customer's internal supervisor, approver, compliance officer, or governance referee merely because it provides the technical tools through which admins act.

If the organization grants admin status improvidently, leaves elevated access in place after a role change, tolerates informal delegation, or fails to monitor who can invite, revoke, edit, review, export, or otherwise influence sensitive workflow data, the resulting consequences remain customer-side governance consequences to the fullest extent permitted by law. GeriPay may rely on visible admin state unless it has actual contrary notice, and the existence of admin-side controls does not imply that GeriPay has assumed the burden of designing or enforcing the customer's internal control architecture.

9.3 Member roles, visibility boundaries, and limited permissions

Member and non-admin access is role-dependent, organization-dependent, and subject to change. A person may be able to upload, review, edit, submit, view, contest, or otherwise interact with some records and not others, and the scope of those permissions may vary across organizations, time periods, workflow states, and internal governance choices. The ability to view or act on one part of the Service does not by itself create authority to approve, override, export, share, change payout-related information, or make binding organizational decisions outside the scope actually granted.

Members and similarly limited users must act only within their assigned permissions and must escalate uncertainty rather than assuming that visible workflow access equals broader authority. The organization bears responsibility for designing those visibility boundaries correctly and for the consequences of granting a person too much access, too little access, the wrong role, or a stale role that no longer matches the person's job function or internal authority.

9.4 Access changes, deactivation, removal, and historical record continuity

Organizations and GeriPay may change, narrow, suspend, deactivate, or terminate access based on role changes, security concerns, internal governance decisions, loss of authority, workspace restructuring, fraud or abuse review, or other legitimate reasons. A person's loss of access to a workspace or feature does not mean the historical records associated with that person's earlier use disappear, become irrelevant, or must be rewritten as if that person had never acted. Historical submissions, edits, approvals, reimbursement activity, payout-related history, report activity, audit trails, and related evidence may remain associated with the workspace and preserved for operational, legal, evidentiary, support, security, or dispute-related purposes.

Users may not circumvent deactivation or removal through alternate credentials, stale sessions, old invites, borrowed access, or indirect use of another person's account. Restoring access, if it occurs at all, remains subject to the organization's current decisions and GeriPay's independent protective discretion. The Service may therefore preserve historical continuity even while current access rights change sharply.

9.5 Internal visibility, audit traces, and accountability within the workspace

The Service may expose receipts, reimbursement records, payout-method information, payment-history records, reports, verification-related materials, notes, corrections, activity history, and audit-style traces to administrators or other authorized workspace participants depending on the organization's chosen roles and permissions. That internal visibility is part of the organization-managed design of the Service and is not, by itself, a confidentiality breach by GeriPay. Organizations are responsible for deciding which internal audiences should be able to see sensitive workflow information and for understanding that broader visibility creates broader internal-exposure consequences.

Users should not assume that information entered into an organization workspace is private from all other authorized participants in that workspace. To the extent permitted by the Service's configuration and the organization's governance choices, internal oversight, auditability, and accountability features may reveal who did what, when, and in relation to which records. The organization bears the risk of overexposure caused by its own role design, audience selection, delegation, and internal-sharing choices.

9.6 Internal policy, approval chains, and organization-side governance

The organization is solely responsible for its own reimbursement, expense, approval, documentation, payout, reporting, retention, escalation, exception, fraud-prevention, and recordkeeping policies, including who may approve what, which supporting materials are required, what exceptions are permitted, what thresholds apply, and how conflicting or suspicious situations should be resolved. GeriPay may reflect, route, display, store, or help organize those choices, but GeriPay does not create them, validate their sufficiency, monitor their consistent application, or adjudicate whether they were followed correctly inside the organization.

Internal disputes about who should have approved a request, who should have seen a record, whether a role should have included a permission, whether an exception should have been granted, or whether a policy was interpreted correctly remain customer-side matters unless GeriPay decides that limited intervention is necessary to protect the Service, preserve evidence, or respond to legal, fraud, abuse, or security concerns. The organization bears the consequences of weak internal controls, weak segregation of duties, poor approval-chain design, stale access, and internal misuse to the fullest extent permitted by law.

Section 10. Customer Data, Inputs, and Rights to Use Service Materials

10.1 Ownership boundaries for Customer Data and Service Materials

As between the Customer and GeriPay, the Customer retains whatever rights it has in the underlying receipt images, uploaded files, supporting materials, notes, explanations, workspace-submitted records, reimbursement-request content, payout-method inputs, payment-history-linked records, Report inputs, support submissions, and other customer-linked or user-linked materials the Customer or its authorized users submit to or generate through the Service. The same general ownership boundary applies where those materials are later displayed in structured form, corrected through review, linked to reimbursement or payout workflows, included in Reports, connected to public or semi-public verification surfaces, or preserved in historical account, Workspace, support, or dispute records. GeriPay does not claim ownership of the Customer's underlying business records merely because the Service hosts, displays, normalizes, extracts, copies, preserves, or otherwise operates on them.

At the same time, customer-retained rights do not narrow or override the operational, security, support, preservation, and defense rights expressly granted in these Terms. They also do not give the Customer any ownership interest in GeriPay's software, interfaces, prompts, templates, workflow logic, models, branding, documentation, infrastructure choices, provider integrations, Service behavior, internal methods, or non-customer-owned internal records. The fact that Customer Data may be processed together with Service Materials, converted into structured records, or reflected in logs, metadata, and technical artifacts does not transfer ownership of GeriPay's systems to the Customer, and the fact that GeriPay creates or preserves operational artifacts does not by itself transfer ownership of the Customer's underlying submitted materials to GeriPay.

10.2 Operational license to host, store, process, and transform submitted materials

The Customer grants GeriPay a non-exclusive, worldwide, royalty-free license to host, store, reproduce, copy, cache, transmit, display, deliver, format, convert, compress, crop, parse, normalize, classify, index, structure, summarize, correlate, back up, archive, preserve, and otherwise use Customer Data and other submitted materials as reasonably necessary to provide, operate, secure, support, maintain, improve, preserve, and defend the Service. This license is intended to cover the real technical and operational work the Service performs, including receipt-upload handling, SmartScan and related extraction or normalization steps, preview and display layers, admin and member Workspace views, reimbursement and payout-related workflows, Payment History displays, Report generation, Verified PDFs, Verification Codes, public or semi-public verification surfaces, support handling, auditability, fraud review, incident response, and lawful response to complaints, claims, investigations, or legal process.

These rights may be exercised directly by GeriPay or indirectly through provider-supported, provider-backed, or layered infrastructure and service-provider arrangements acting on GeriPay's behalf. The license extends to both present and future covered Service features reasonably related to the operation of the product, and it applies across organization-managed Workspace use, support use, security review, archive and backup use, and other lawful operational contexts tied to the Service. This operational license does not transfer ownership of Customer Data to GeriPay, but it does remain broad enough to prevent later arguments that ordinary hosting, transformation, troubleshooting, preservation, or provider-supported operation somehow fell outside the parties' agreement.

10.3 Derived records, metadata, audit trails, and historical continuity

GeriPay may create and retain extracted fields, structured receipt records, review and correction history, workflow states, reimbursement history, approval history, payout history, payment-history records, previews, thumbnails, report artifacts, verification-linked artifacts, duplicate or normalized records, logs, telemetry, timestamps, chronology, legal-acceptance evidence, hashes or comparable integrity markers, support artifacts, incident-review materials, escalation packets, and other technical, operational, or evidentiary artifacts derived from customer data, Service use, or ordinary platform operation. These records may exist even where a user never manually typed every field reflected in them, because the Service necessarily creates machine-generated, system-generated, reviewer-generated, or workflow-generated layers in the course of operating the product.

Those derived records and operational artifacts may remain important even if the original upload is later replaced, removed, archived, corrupted, no longer user-accessible, or no longer visible in the same form. GeriPay may preserve, review, correlate, disclose as permitted by these Terms, and rely on such records for service continuity, support, auditability, fraud review, incident response, dispute defense, legal process, and other lawful operational reasons. The customer agrees that a later change in visible record state does not erase the existence or significance of earlier logs, metadata, preserved copies, or historical workflow evidence. GeriPay may also create and use de-identified or aggregated information that does not identify the customer or an individual for internal analytics, quality review, reliability work, security analysis, capacity planning, and service improvement.

10.4 Security, support, integrity, and service-defense use

GeriPay may use Customer Data and related operational artifacts to troubleshoot failed uploads, diagnose SmartScan errors, investigate broken Reports or verification behavior, reconcile reimbursement or payout-history mismatches, analyze product quality, maintain reliability, test fixes, harden workflows, and otherwise support and maintain the Service. GeriPay may also use those same records to monitor for fraud, abuse, policy violations, account compromise, suspicious activity, public-surface misuse, provider-caused issues, data-integrity problems, and cybersecurity events. In doing so, GeriPay may review and correlate records across accounts, Workspaces, users, sessions, devices, uploads, reimbursements, payout methods, Payment History, Reports, verification activity, support history, and legal-acceptance evidence where reasonably necessary to protect the Service, its providers, affected organizations, and other users.

GeriPay may preserve and use relevant records to enforce these Terms, respond to complaints, answer legal process, defend claims, cooperate with advisors or insurers, support audits, and protect its rights and the integrity of the Service. These rights are practical and defensive in nature. They do not create a promise that GeriPay will pre-review every upload, continuously monitor every workflow, perfectly classify every anomaly, or always prevent misuse before harm occurs. The customer acknowledges that security, support, and enforcement use of records is part of the ordinary operation of the Service rather than a special exception that applies only after a known dispute has already matured.

10.5 Customer-side permissions, authority, and submission assurances

The customer represents and warrants that it, and the users acting through its workspace or under its authority, have all rights, permissions, authority, notices, consents, and other lawful basis necessary to submit customer data and other materials to the Service and to instruct GeriPay to host, process, transform, preserve, display, generate, export, transmit, and otherwise use those materials as contemplated by these Terms and the Service design. This includes receipt images, supporting documents, reimbursement and payout-related records, personal information, third-party information, business records, report inputs, support submissions, and other materials that may contain confidential, proprietary, employment-related, financial, or other sensitive content. The customer must not cause GeriPay to receive, use, or disclose materials the customer is not authorized to provide, or to operate on materials in a way that violates law, contract, confidentiality duties, internal policy, or the rights of others.

The customer remains responsible for deciding what should be uploaded, what should be redacted, what should be shared inside or outside the organization-managed workspace, what internal approvals are required, what original records should be preserved outside the Service, and whether a given record may lawfully be used for reimbursement, employment, accounting, tax, audit, litigation, or other downstream purposes. GeriPay may rely on the customer's submission instructions and apparent authorization unless GeriPay has actual contrary knowledge. If the customer, its users, or its representatives submit material without the necessary rights or authority, the resulting risk, including confidentiality breaches, third-party claims, internal-policy violations, and disputes over what should have been uploaded or shared, remains on the customer side to the fullest extent permitted by law.

10.6 No general duty to pre-screen or verify customer-provided content

GeriPay is not required to pre-screen, pre-approve, or independently verify every upload, record, correction, explanation, reimbursement request, payout-method entry, support submission, report input, or other customer-provided or user-provided material before the Service hosts, processes, displays, transforms, or preserves it. Technical ingestion, SmartScan processing, preview generation, workflow routing, report generation, verification-code issuance, or storage-backed availability do not mean GeriPay has confirmed accuracy, legality, authenticity, confidentiality compliance, internal-policy compliance, authority, or suitability for the customer's intended downstream use. The customer remains the primary party responsible for the source-record layer, the decision to submit it, and the decision to rely on or act on it.

GeriPay may, but is not obligated to, review, refuse, remove, isolate, disable access to, challenge, preserve, escalate, or report customer-provided materials or related records where GeriPay believes doing so is appropriate for security, abuse prevention, legal compliance, provider management, platform integrity, dispute handling, or other protective reasons. The fact that GeriPay sometimes exercises that discretion does not create a general monitoring duty, a duty to catch every problem, or a certification relationship with the customer or any outside viewer. Likewise, the fact that GeriPay does not act in one case does not waive its rights in another case or shift responsibility for the underlying content away from the customer and its authorized users.

Section 11. Source Records, Uploads, and Original-Material Responsibility

11.1 Responsibility for uploaded source materials

The customer and its authorized users are responsible for the source materials they upload, submit, attach, transmit, or otherwise introduce into the Service, including receipt images, screenshots, PDFs, supporting documents, notes, explanations, reimbursement-linked materials, payout-related supporting materials, and other records used to support workflow activity inside the organization-managed workspace. That responsibility includes deciding whether a source record is genuine, complete, lawfully obtained, sufficiently related to the claimed business or reimbursement context, and appropriate to submit at all. GeriPay is a software and record-handling platform, not the original creator, issuer, or custodian of most source records that appear in the Service, and it does not become responsible for the underlying truth of a document merely because the document was uploaded, stored, displayed, routed, reviewed, or later referenced in downstream workflow records.

If a source record is false, misleading, incomplete, unauthorized, stale, unrelated to the claimed event, or otherwise improper, the resulting risk remains on the customer side even if the record is technically processable inside GeriPay. Submission of a source record does not mean GeriPay has authenticated it, verified the merchant or issuer, validated the underlying transaction, confirmed entitlement, or independently checked that the record satisfies the customer's internal policy, tax, accounting, employment, audit, litigation, or regulatory requirements. The customer remains responsible for deciding what record is being submitted, what it is supposed to prove, and whether it is fit for the customer's intended downstream use.

11.2 Image quality, legibility, and technical sufficiency

Source materials may be unreadable, only partly readable, or misleadingly incomplete even when they can be uploaded or viewed inside the Service. Blur, glare, shadow, low resolution, skewed angles, folds, tears, faded print, handwriting, partial capture, cropped edges, compression artifacts, long or unusually formatted receipts, multilingual text, thermal-print decay, obstructed fields, screenshots that omit context, and similar problems may all prevent accurate reading or later review. A file may therefore be technically accepted, stored, converted, previewed, or associated with a workflow while still being insufficient for reliable extraction, review, reimbursement use, reporting, or later evidentiary reliance.

Technical ingestion does not equal technical sufficiency, and technical sufficiency does not equal interpretive reliability. A viewable image can still be missing critical detail. A clean-looking preview can still omit portions of the original. A file that appears adequate for a quick on-screen review may still be inadequate for SmartScan, later correction, report generation, dispute handling, or outside review. The customer remains responsible for determining whether the uploaded source actually captures the material information the customer expects the Service, its users, or later viewers to rely on.

11.3 Manipulated, forged, altered, or misleading source materials

You may not use the Service to submit, store, organize, route, or legitimize fabricated receipts, forged documents, altered images, composited or stitched screenshots, duplicated source records, selectively cropped records, edited totals, edited taxes, edited tips, edited dates, edited merchant identities, edited approval context, or other source materials that are false, misleading, or presented out of context. A technically readable image can still be deceptive. A receipt that looks ordinary can still be unrelated to the claimed expense, duplicated across claims, altered after issuance, or combined with false notes, false categories, false policy context, or false approval narratives designed to make misconduct appear routine.

GeriPay may process, display, preserve, or even generate downstream workflow records from manipulated source materials without independently curing their defects or detecting the manipulation before harm occurs. Successful upload, preview, SmartScan processing, saving, reimbursement linkage, report inclusion, payment-history linkage, or appearance in public or semi-public verification surfaces does not mean the source material was authentic, complete, or trustworthy. GeriPay may investigate, restrict, suspend, preserve, correlate, and rely on records related to suspected manipulation or fraud, but it does not guarantee that every falsified, altered, or misleading source record will be identified before use, sharing, or downstream reliance.

11.4 Third-party and personal data embedded in uploads

Source materials submitted to the Service may contain third-party or sensitive information, including names, contact information, employee information, merchant information, card-adjacent details, transaction references, account-adjacent details, tax-related details, location information, internal notes, signatures, or other confidential, proprietary, or regulated information. The customer is responsible for deciding whether such information should be uploaded, whether it should be redacted first, whether additional notice or consent is required, whether the organization is authorized to route that material through the Service, and whether the presence of that information changes how the record may lawfully be used, shared, exported, or preserved.

If the customer uploads source materials containing unnecessary, excessive, unauthorized, or improperly disclosed third-party information, GeriPay is not responsible for that submission decision merely because the Service can technically host, process, display, or preserve the file. Once submitted, such materials may move through ordinary Service operation, including provider-supported storage, SmartScan or review-related handling, support review, fraud review, incident response, report generation, archive and backup layers, and lawful preservation or disclosure paths described elsewhere in these Terms and the Privacy Policy. The customer therefore bears the burden of deciding what should enter the Service in the first place.

11.5 Preservation of originals and external records

Unless GeriPay expressly agrees otherwise in a separate written agreement, the Service is not the customer's sole or canonical books-and-records repository for original receipts, original supporting documents, external accounting evidence, payroll evidence, tax records, employment records, litigation-hold collections, or other source materials the customer may need to preserve outside the product. The customer remains responsible for maintaining whatever original files, hard copies, inbox records, bank records, merchant communications, approval records, or parallel systems the customer believes are necessary for its own legal, accounting, tax, employment, audit, compliance, insurance, regulatory, investigative, or dispute needs.

The existence of a saved receipt record, SmartScan output, reimbursement request, report, Verified PDF, verification code, payment-history record, archived artifact, or preserved evidence collection inside GeriPay does not guarantee that the original source file remains available in the same form, contains all relevant context, or can substitute for the original in every downstream setting. Structured records and generated outputs may help organize workflow and preserve part of the historical picture, but they do not relieve the customer of the responsibility to keep source materials and outside records where originals or parallel records matter.

11.6 Missing, deleted, corrupted, or inaccessible source files

Source materials or related files may become unavailable, corrupted, partially unreadable, superseded, overwritten, archived, deleted, inaccessible, or otherwise degraded because of user action, admin action, synchronization issues, provider issues, conversion failure, storage-path issues, permission changes, public-surface changes, suspension, termination, incident response, preservation handling, or other technical or operational events. In some cases an original source file may no longer be readily available even though derived records, logs, SmartScan output, review history, reimbursement history, report artifacts, or preserved evidence linked to that file still remain. In other cases an original image may remain while some derived or downstream view becomes unavailable, outdated, or incomplete.

GeriPay does not guarantee perpetual availability, perfect restoration, perfect file integrity, or exact reconstruction of every missing, altered, historical, or inaccessible source file. The customer should assume that failures, deletions, corruption, provider incidents, access restrictions, and preservation-driven lifecycle changes can affect what remains retrievable and in what form. That is one reason the customer must preserve originals and important external records outside the Service where needed. Later warranty, liability, suspension, termination, and evidence-preservation sections should be read consistently with this subsection rather than as creating a broader restoration duty.

Section 12. Receipts, SmartScan, and Automated Extraction Features

12.1 Receipt drafts, saved records, and workflow stages

The Service may create, store, and display multiple layers of receipt-related records, including source images, draft receipt records, review-stage records, finalized or saved records, corrected records, and later downstream records that depend on those earlier layers. Those states are operational stages within the Service. They help organize how a receipt moves through capture, extraction, review, correction, storage, reimbursement use, reporting, and related workflows, but they do not by themselves establish that the underlying receipt was authentic, complete, unaltered, policy-compliant, legally sufficient, or suitable for reliance without further review.

The existence of a draft, saved, corrected, accepted, finalized, or similar state does not mean that the original image was reliable, that every extracted field was correct, or that every later viewer should treat the displayed record as a conclusive substitute for the original source. The source image, the extracted record, the corrected record, and the displayed summary may all carry different meanings and different risks at the same time. No workflow label in this chapter should be overread as a certification of truth, completeness, or downstream legal consequence.

12.2 SmartScan, OCR, AI-assisted extraction, and automation scope

GeriPay may use OCR, SmartScan, AI-assisted extraction, heuristic parsing, classification logic, normalization logic, provider-supported inference systems, and related automation to read receipt images and attempt to structure fields such as merchant name, date, subtotal, total, tax, tip, payment details, identifiers, codes, line items, categories, and related metadata. Those functions are intended to assist with record capture and workflow organization. They are not promises that every receipt can be read correctly, that every relevant field will be found, or that every structured result will match the legal, financial, accounting, or business meaning a human reviewer might later assign to the source material.

The methods used to produce SmartScan results may change over time. GeriPay may change prompts, models, provider pathways, preprocessing steps, fallback logic, escalation logic, or mixed automated-plus-human workflows without preserving identical prior behavior. Similar-looking receipts may produce different outputs at different times, and the same receipt may be processed differently after a system change, provider change, maintenance event, or workflow redesign. Nothing in this subsection guarantees static extraction behavior or stable output quality across time, providers, or document conditions.

12.3 Inaccuracy, omission, misclassification, and field-evidence limits

SmartScan and related extraction may misread or fail to capture merchants, dates, subtotals, totals, taxes, tips, discounts, fees, payment methods, identifiers, line items, categories, and other receipt details. They may omit fields, flatten distinct fields together, duplicate fields, invent plausible-but-wrong fields, misclassify categories, or map evidence imperfectly. A result may look polished, internally consistent, and complete while still being materially inaccurate or incomplete. Clean formatting and confident-looking structure do not make extracted data trustworthy by default.

These limitations are especially likely where source images are blurred, glared, shadowed, low resolution, partially captured, cropped, skewed, folded, torn, faded, handwritten, unusually formatted, long, multilingual, thermal-printed, compressed, or otherwise difficult to interpret. GeriPay does not guarantee that extracted data, field-evidence links, or displayed mappings are complete, correct, or suitable for reliance without independent review. The inability to detect, preserve, or interpret all visible or relevant source material is a foreseeable risk of this feature set.

12.4 User correction, admin correction, and residual error risk

The Service may permit users or administrators to correct, override, supplement, replace, recategorize, or otherwise edit SmartScan output and receipt-related fields. Those corrections may improve accuracy, may fail to resolve existing problems, or may introduce new problems. Different reviewers may reasonably or unreasonably interpret the same receipt differently, and a later human-edited record may conflict with the original image, the first extraction result, earlier edits, related supporting records, or downstream workflow use.

GeriPay does not independently verify that a corrected or overridden version is more accurate than an earlier extracted version or than the underlying source image. Manual review is an important customer-side control, but it is not a guarantee of correctness, completeness, policy compliance, entitlement, or fraud-free status. The fact that a record was reviewed, corrected, or saved after review does not eliminate residual risk or foreclose later disputes about what the source actually showed.

12.5 Calculations, categorizations, and structured outputs

The Service may calculate or display derived totals, subtotals, tax breakdowns, tips, line-item summaries, category assignments, payment indicators, merchant attributes, or other structured outputs based on available receipt data and workflow logic. Those outputs are operational aids. They are not authoritative accounting classifications, tax determinations, payroll conclusions, legal conclusions, fraud determinations, or reimbursement-entitlement decisions. Derived or categorized output may depend on incomplete data, inferred relationships, user changes, provider behavior, or assumptions built into the product's current logic.

No customer, user, reviewer, auditor, or other viewer should treat those structured outputs as self-proving support for accounting treatment, tax treatment, payroll treatment, business-purpose validation, merchant legitimacy, or policy compliance. If the customer needs a conclusion in any of those areas, the customer must independently review the underlying materials and apply its own policy and professional judgment rather than relying on the existence of a structured field or system-generated category.

12.6 Hard cases, exception handling, and escalation pathways

Some receipts will be hard cases. Complex merchant layouts, low-confidence images, unusual tax or payment formats, partial captures, conflicting data, duplicate-looking inputs, and other difficult conditions may lead to partial extraction, low-confidence output, unresolved fields, exception states, manual follow-up, or escalation-style handling. GeriPay may preserve such materials for further review, may surface limited output, may defer or narrow processing, or may allow the customer to decide how to proceed with incomplete information.

GeriPay does not promise that every hard case will be fully resolved, that every low-confidence input will become a high-confidence record, or that every escalation path will remain available in the same form over time. Some receipt records may remain incomplete, contested, or only partially structured. The customer remains responsible for deciding whether the available information is sufficient for the customer's intended downstream use.

12.7 SmartScan outputs as assistive rather than conclusive records

SmartScan outputs, receipt summaries, extracted fields, saved receipt records, review-stage displays, and related metadata are assistive operational records only. They may help the customer organize review and support later workflow steps, but they do not certify the underlying facts, merchant behavior, transaction legitimacy, business purpose, expense legitimacy, reimbursement eligibility, policy compliance, accounting treatment, tax treatment, or legal sufficiency of the receipt or the event it allegedly reflects. GeriPay does not become a document authenticator, fraud-clearing service, accounting reviewer, or reimbursement decision-maker merely because a receipt was processed, structured, displayed, reviewed, or saved in the Service.

Successful processing, a clean-looking output, a completed review flow, or a saved or corrected state does not mean the source was genuine, the extracted information was complete, or the downstream use is safe. Errors, omissions, manipulations, and misunderstandings at the receipt layer can propagate into reports, reimbursement requests, payout-related records, payment-history displays, and verification-linked artifacts. Customers must therefore review receipt-layer outputs independently and must not rely on them as conclusive records of underlying real-world truth.

Section 13. Reports, Exports, Verified PDFs, and Public Verification Features

13.1 Report generation and export functionality

GeriPay may generate Reports, summaries, exports, PDFs, Verified PDFs, compilations, and verification-linked artifacts from records then available in the Service. Those outputs depend on the underlying receipt records, reimbursement records, payout-related records, filters, date ranges, selection logic, workflow states, formatting logic, template rules, storage availability, provider availability, and other then-current technical conditions. They are software-generated product artifacts assembled from available records; they are not independent professional work product, audit opinions, regulator-ready filings, or certified documentary packages merely because they are polished, downloadable, or presented in formal-looking document form.

The customer is responsible for deciding what records to include, what date range or dataset is appropriate, and whether the resulting report is fit for the customer's intended purpose. GeriPay does not independently determine that a report contains every relevant record, every necessary explanation, every later correction, or every item an auditor, advisor, regulator, court, insurer, or counterparty might want to see.

13.2 Snapshot nature of reports and data-cutoff limits

A report or export reflects only the records and states captured at the relevant generation moment. It may not reflect later corrections, later disputes, later reversals, later reimbursement changes, later payout issues, later deactivations, later exclusions, later evidence discovery, or later system changes. A document that was accurate enough for a limited purpose at one moment may become incomplete, superseded, or misleading when later events occur. Reports should therefore be understood as snapshots, not as ever-current truth.

The fact that a report was generated, downloaded, or presented at one time does not require GeriPay to ensure that all copies remain aligned with later changes. Newer outputs may replace or supersede older outputs, but older outputs may still continue to exist in downloads, inboxes, shared folders, archives, backups, or litigation-preserved copies. The customer is responsible for deciding whether a previously generated artifact is still appropriate to rely on or share.

13.3 Verified PDFs and meaning limits of verification status

Terms such as "Verified PDF," "verified," or similar verification-related labels must be read narrowly. In this context, verification ordinarily refers only to limited record linkage, code-based matching, artifact generation, or comparable system-level confirmation within GeriPay's own environment. It does not mean that GeriPay independently audited the underlying receipts, confirmed the underlying transactions, certified legal or accounting conclusions, approved reimbursement entitlement, or endorsed the report for any special-purpose reliance by the customer or by outsiders.

The presence of a verification-related label does not create a trust seal, certification-grade review, fraud-clearance signal, regulator approval, audit opinion, or authenticity guarantee for underlying facts. A verified artifact may still depend on flawed source records, incomplete datasets, stale workflow states, misclassified records, or customer-side misunderstandings. The customer and any other viewer must therefore treat verification terminology as narrow product terminology, not as a broad assurance regime.

13.4 Verification Codes, the Public Verification Page, and outward-facing reliance

Verification Codes and the Public Verification Page are limited outward-facing product features. They may permit code-holders or viewers to see that certain report-related records or artifacts appear linked within GeriPay's verification system at the relevant time or in the then-current verification view, and they may expose limited associated information depending on the product design then in use. The Customer is responsible for deciding whether, when, and to whom to disclose verification-linked artifacts, codes, or Reports, and for understanding that such sharing can create broader visibility and broader reliance risk than private Workspace use alone.

Outside viewers must not overread what public verification confirms. The Public Verification Page does not prove that the underlying receipts were authentic, that the underlying transactions were lawful or business-related, that the reimbursement workflow was correct, that any accounting or tax treatment was proper, or that an outsider should rely on the Report for a particular legal, financial, regulatory, or litigation purpose. Public verification is a narrow record-matching and artifact-display feature, not an invitation to broad outsider reliance.

13.5 Report sharing, download risk, and downstream redistribution

Once a Report, export, PDF, Verified PDF, screenshot, or verification-linked artifact is downloaded, emailed, printed, stored outside the Service, copied into another system, or otherwise redistributed, GeriPay may no longer control how that artifact is handled, interpreted, altered, preserved, or combined with other materials. Files may be forwarded, duplicated, re-labeled, excerpted, context-stripped, stored in insecure places, or presented without later corrections or limitations that existed within the Service. The Customer bears responsibility for its downstream distribution choices and for deciding whether a recipient should receive an artifact at all.

GeriPay does not assume responsibility for how customer-chosen recipients, code-holders, advisors, employers, auditors, vendors, regulators, counterparties, courts, or other third parties store, interpret, share, or misuse a distributed artifact. The Customer's decision to distribute a Report or code does not convert GeriPay into the Customer's sponsor, certifier, or guarantor for the downstream recipient's reliance.

13.6 Revocation, replacement, archival, and preservation of report artifacts

GeriPay may replace, regenerate, supersede, archive, preserve, withdraw, narrow, or otherwise change access to report artifacts and verification-linked materials over time. Verification status may change, codes may be disabled or replaced, older outputs may be superseded, and access patterns may evolve as records change, policies change, disputes arise, or preservation needs emerge. At the same time, older copies may continue to exist in customer storage, recipient systems, downloaded files, backups, preserved evidence collections, or other places outside GeriPay's present control.

Revocation or replacement of a code or artifact does not guarantee the disappearance of every historical copy or every previously exposed record. Conversely, preservation of an archived or litigation-hold copy does not mean that copy remains appropriate for operational reliance. GeriPay may keep historical artifacts when needed for security, audit, fraud review, dispute handling, legal process, or internal defense, and no single lifecycle expectation should be assumed for every generated document.

13.7 No outsider duty and no special reliance relationship

GeriPay does not undertake a special duty to outside auditors, counterparties, employers, regulators, vendors, insurers, courts, code-holders, public viewers, or any other third party merely because Reports can be generated, verification-linked artifacts can be created, or the Public Verification Page or another public or semi-public verification surface can be viewed. These features do not create a third-party-beneficiary relationship, a certification relationship, a professional-reporting relationship, or any other special reliance relationship between GeriPay and outside viewers.

If the Customer chooses to present a Report or verification-linked artifact to a third party, that decision remains the Customer's decision. Any outsider who views, receives, or relies on such material does so, if at all, only to the extent the relevant surface or artifact presents or incorporates these Terms and to the extent applicable law permits, and otherwise at that outsider's own risk. The existence of a public or shareable feature should not be read to expand GeriPay's duties beyond the limited product functions expressly described in these Terms.

Section 14. Reimbursement Requests and Internal Approval Workflows

14.1 Reimbursement-request creation and eligibility gating

The Service may allow reimbursement requests to be created only when certain operational prerequisites have been met, including linkage to saved receipt records, completion of particular review stages, satisfaction of current product rules, or other workflow conditions then in effect. Those gating rules are technical and operational rules within the Service. They do not mean that GeriPay has independently determined that the underlying expense is reimbursable, that the user is entitled to payment, or that the organization is legally or contractually required to pay.

The creation of a reimbursement request means only that a workflow record has been created inside the Service. It may reflect user-entered data, linked receipt data, then-visible workflow conditions, and organization-controlled context. It is not a debt acknowledgment by GeriPay, not a payor commitment by GeriPay, and not a conclusive statement that a request is valid, complete, singular, policy-compliant, or ready to be paid in the real world.

14.2 Organization review, approval, denial, and escalation paths

Organizations control their own reimbursement review, approval, denial, reduction, exception, escalation, and override logic, whether that logic is formal, informal, entirely inside the Service, partly outside the Service, or supported by additional off-platform communication and decision-making. GeriPay may route, store, display, or record review activity and status changes, but it does not become the approver, adjudicator, payroll department, compensation decision-maker, or policy source for the customer merely because those workflow events appear in the product.

An approval-like state in the Service therefore reflects a customer-controlled workflow act, not an independent GeriPay judgment that reimbursement should occur. A denial-like state likewise does not mean GeriPay concluded payment was improper. The customer remains responsible for who may approve, what exceptions are permitted, what evidence is required, and whether a given request should be granted, reduced, delayed, disputed, or denied.

14.3 Operational state labels only

Labels such as pending, approved, denied, contested, canceled, paid, failed, ready, or similar workflow indicators are operational labels reflecting the state of records visible within the Service at a given time. They are not independent guarantees of legal validity, internal policy correctness, managerial authority, funding, destination correctness, actual transfer initiation, actual transfer completion, or final settlement. A positive-looking label does not mean payment must occur, and a negative-looking label does not mean every underlying fact was false or improper.

Workflow labels may also lag, be revised, be superseded, be affected by asynchronous updates, or reflect only part of a more complicated real-world situation. The customer and its users must therefore treat such labels as operational messaging only and must not rely on them as self-proving conclusions about entitlement, approval quality, or payment outcome.

14.4 Member actions and exceptions

Where the Service permits it, members or other users may submit requests, cancel requests, contest outcomes, respond to exceptions, resubmit materials, or otherwise participate in reimbursement workflows. Whether those actions are available, when they are available, and what effect they have may vary by organization policy, workflow state, role assignment, technical design, and GeriPay's then-current operational controls. No user should assume that every exception path, appeal-like path, or resubmission path will always remain available or that a visible option means a particular substantive outcome will follow.

Customer-side process variation matters here. One organization may permit resubmission or contesting in a scenario where another does not. One workflow may be locked after a certain point while another remains editable. GeriPay may also limit or disable actions for integrity, security, abuse, support, or operational reasons. The presence or absence of a member-side action path does not alter the organization's ultimate responsibility for policy, authority, review, and final internal decision-making.

14.5 Duplicate, inconsistent, or disputed reimbursement requests

Reimbursement workflows may involve duplicate requests, overlapping requests, split requests, resubmitted requests, stale receipts, contradictory explanations, inconsistent supporting records, disputed request histories, retroactive edits, or internal disagreement about whether the same underlying event should be reimbursed at all. A request already being "in the system" does not mean it is unique, clean, uncontested, or correctly assembled. Underlying receipt-layer errors or manipulations can also propagate into reimbursement requests without being automatically cured by the later workflow.

GeriPay may surface, restrict, flag, preserve, or otherwise respond to some duplicate-looking or disputed scenarios, but GeriPay does not guarantee detection, reconciliation, or correct resolution of every overlap, duplicate, dispute, or policy conflict. The customer remains responsible for reviewing anomalies, deciding how duplicates and conflicts should be handled, and determining whether any request should actually be approved or paid.

14.6 No guarantee of reimbursement approval, amount, timing, or funding

GeriPay does not guarantee approval, amount, timing, funding, initiation, completion, or successful final handling of any reimbursement request. GeriPay does not determine whether sufficient funds exist, whether internal approvals were proper, whether an organization remains willing to pay, whether a downstream payout will be attempted, or whether a downstream payout will succeed if attempted. This remains true even where the Service shows optimistic, positive, or advanced workflow states.

Approval-like workflow states and reimbursement-request history do not create a promise by GeriPay that money will move, that it will move in the requested amount, that it will move on a desired timeline, or that it will reach the correct recipient without later failure, delay, return, reversal, dispute, or correction. Reimbursement workflow and payout execution are separate layers with separate actors, dependencies, and failure modes, and the customer must not collapse them into one guarantee.

Section 15. Payout Methods, Payment History, and Operational Payment Records

15.1 Payout-method setup, maintenance, and destination information

The Service may collect, store, display, or update payout-method records and related destination information, including beneficiary-related information, bank-related information, routing-related information, account-related information, default-method indicators, and other metadata needed to support payout-adjacent workflows. Those records are operational destination records within the Service. They may support workflow continuity and display, but they do not by themselves prove that the destination is current, valid, reachable, supported, controlled by the intended recipient, or authorized by every necessary customer-side decision-maker.

The user and organization remain responsible for the accuracy, authorization, continued validity, and change control of payout-destination information. A stored method, visible default, or successfully saved update does not mean GeriPay verified ownership, confirmed entitlement, or guaranteed that a downstream provider or bank will accept or complete any later transfer involving that destination.

15.2 Beneficiary validation and wrong-destination risk allocation

GeriPay does not guarantee that a payout destination belongs to the intended person, remains controlled by that person, corresponds to a legally entitled beneficiary, or is free from fraud, redirection, typo, stale-data issues, account-takeover issues, social-engineering issues, recycled identifiers, unauthorized changes, or other destination-integrity failures. Wrong-recipient and wrong-destination scenarios can arise from user error, admin error, stale records, internal approval mistakes, phishing, impersonation, provider-side constraints, bank-side behavior, or a combination of those causes.

The customer side bears primary responsibility for validating beneficiary identity, payee entitlement, destination ownership, destination changes, and the internal approvals required before any payout-related action proceeds. GeriPay does not independently verify who should receive funds, whether the beneficiary is still the correct beneficiary, or whether a changed destination was legitimate. The customer must therefore maintain its own change-control, review, and confirmation procedures around payout-method management.

15.3 Payment history and operational event records

Payment-history views, payout-state displays, and related event logs are operational records of statuses, attempts, updates, provider messages, and other events as they become visible within the Service. They are not bank statements, settlement confirmations, treasury ledgers, or final legal proof of who received funds, when funds became available, what net amount was ultimately received, or whether a downstream event remained final and unreversed. They may be influenced by customer-side inputs, provider-side signals, asynchronous updates, and later corrections.

A payment-history entry may therefore be incomplete, delayed, revised, contradicted by a downstream record, or later affected by return, reversal, retry, dispute, correction, or synchronization lag. The customer must not treat a visible payment-history record as a complete substitute for bank, processor, payroll, accounting, or other downstream records relevant to the customer's actual finance operations.

15.4 Delays, failures, returns, reversals, and retries

Payout-adjacent workflows may be delayed, blocked, failed, returned, reversed, retried, partially completed, duplicated, or otherwise disrupted for many reasons, including customer-side approval delays, stale destination information, provider review, bank review, unsupported account types, fraud controls, legal restrictions, corridor restrictions, holidays, weekend cutoffs, provider outages, network failures, missing callbacks, asynchronous processing, duplicate attempts, or later-discovered errors. Real-world payment outcomes are often messier than a single clean lifecycle suggests.

Even after a payment-history record appears to reflect progress or completion, later return, reversal, clawback, retry, partial failure, blocked release, bank rejection, or disputed outcome may still occur. GeriPay does not guarantee a neat one-pass payout lifecycle, does not guarantee that every downstream actor will behave consistently or transparently, and does not guarantee that the first visible outcome in the Service will remain the final real-world outcome.

15.5 Wrong amount, wrong timing, and inconsistent downstream outcomes

Amounts, dates, destinations, and outcome signals may be wrong, stale, conflicting, or only partially updated across systems. The requested amount, the internally approved amount, the initiated amount, the recorded amount, and the amount ultimately available to a beneficiary may differ because of policy reductions, duplicate detection, split payouts, rounding, fees, reversals, return adjustments, currency effects, corrections, or other customer-side or provider-side events. Likewise, timing signals in the Service may not match recipient-bank release timing, downstream settlement timing, or later correction timing.

The customer must therefore avoid treating any single Service record as conclusive proof of final amount or final timing. GeriPay does not guarantee parity between visible workflow amounts and real-world net amounts, and it does not guarantee that conflicting downstream signals will be resolved instantly or in the customer's preferred sequence.

15.6 Provider, bank, and network dependence

Payment-adjacent workflows depend on providers, banks, payout rails, networks, storage systems, messaging systems, callbacks, infrastructure components, and other downstream actors outside GeriPay's direct control. Those third parties may experience downtime, maintenance, policy changes, review holds, volume limits, corridor restrictions, unsupported-format problems, missing or duplicated callback behavior, delayed updates, routing errors, institution-level issues, or other operational failures that affect payout-related outcomes or the visibility of those outcomes in the Service.

GeriPay does not control those external rails or actors and does not guarantee their availability, consistency, security posture, legal compliance, operational quality, or response timing. The use of a payment-adjacent workflow in the Service therefore does not mean GeriPay has assumed the obligations of the downstream provider, the bank, or the rail involved, and it does not create a warranty that GeriPay will know every downstream detail immediately or that every provider-side problem will be surfaced perfectly inside the Service.

15.7 Customer reconciliation and exception-handling obligations

Customers must reconcile reimbursement, payout-method, and payment-history records against their own bank, provider, payroll, accounting, treasury, and internal approval records as appropriate. Customers must investigate anomalies, confirm recipients, confirm whether funds were actually received where that matters, track returns and reversals, address duplicate-looking events, and handle internal disputes, corrections, and exception states using their own finance and governance processes. GeriPay may preserve workflow records that assist with those efforts, but it does not assume the customer's finance-operations, treasury, payroll, accounting, or dispute-handling duties.

Failure to reconcile, investigate, or confirm downstream outcomes remains a customer-side failure. The customer may not rely solely on the existence of payment-history entries or payout-method records as a substitute for appropriate finance controls, beneficiary validation, exception handling, or downstream confirmation. If the customer needs proof of receipt, settlement finality, reconciliation completeness, or accounting treatment, the customer must obtain and evaluate that proof independently of GeriPay.

Section 16. Customer Operational Responsibilities

16.1 Internal policy design and decision responsibility

The organization is solely responsible for establishing, maintaining, communicating, updating, and enforcing its own expense, reimbursement, payout, documentation, retention, accounting, approval, and related internal policies. This includes deciding what is reimbursable, what is not reimbursable, what supporting materials are required, who may approve or reject requests, what timing or category limits apply, what exceptions are permitted, and how disputes or escalations should be handled. GeriPay may provide workflows through which those policies are expressed operationally, but GeriPay does not author those policies, interpret them for the customer, or guarantee that the Service enforces every customer-side rule exactly as the customer might intend in every circumstance.

No screen, workflow, status label, dashboard view, support interaction, report, or visibility setting should be read to mean that GeriPay has become the customer's policy owner, internal reviewer, payroll department, compliance office, or finance authority. The customer remains responsible for deciding what actions should occur and for bearing the consequences of policy ambiguity, policy miscommunication, weak exception handling, or weak managerial oversight.

16.2 Review, validation, and approval responsibility

The customer must independently review and validate receipts, uploaded materials, SmartScan outputs, extracted fields, corrected fields, reimbursement requests, payout-method details, payment-history entries, reports, exports, verification-linked artifacts, and other Service-presented records before relying on them for approval, payment-adjacent action, accounting treatment, policy enforcement, reporting, audit support, tax treatment, legal use, or any other consequential purpose. SmartScan, draft states, review states, recommendation-like displays, workflow labels, and visible completion markers are not substitutes for customer-side judgment and do not eliminate the need for human review where the customer intends to act on the information.

The customer bears the risk of failing to catch inaccurate, incomplete, duplicate, altered, misleading, unauthorized, stale, or contextually misunderstood records before relying on them. GeriPay may help structure, display, or preserve workflow information, but it does not assume the duty to determine whether an expense is legitimate, whether a record is authentic, whether an exception is proper, whether an approval should be granted, or whether a displayed output is sufficient for the customer's downstream use.

16.3 Beneficiary, destination, and funds-control responsibility

The organization and its authorized users are responsible for confirming the identity, entitlement, and appropriateness of intended recipients, payees, beneficiaries, payout methods, routing information, account information, amount logic, timing logic, and any other customer-side instruction that could affect where value is ultimately directed. The customer must independently verify that payout-related changes are legitimate, that stored destination data remains current and correct, that the intended recipient is the correct recipient, and that the customer-side approvals required before moving forward have actually been obtained.

The customer is also responsible for its own internal funds controls, segregation of duties, review layering, reconciliation processes, exception handling, and escalation when payout-related data looks suspicious, inconsistent, stale, or potentially misdirected. GeriPay does not validate beneficiary ownership, decide entitlement, or guarantee that a visible payout method or payment-history record points to the right person, the right account, the right amount, or the right timing.

16.4 Accounting, tax, payroll, legal, HR, and compliance responsibilities

The customer remains solely responsible for accounting classification, general-ledger treatment, expense categorization, reconciliation against external systems, tax treatment, deductibility analysis, withholding implications, payroll interaction, wage-and-hour implications, worker classification, employment-law obligations, HR policy application, legal compliance, privacy obligations arising from customer-side sharing or uploads, regulated reporting, and any comparable professional, regulatory, or legal consequence associated with the customer's use of the Service or reliance on Service-presented information. GeriPay does not determine whether a record should be booked in a particular way, reimbursed in a particular way, taxed in a particular way, treated as wages or non-wages, preserved for a particular filing obligation, or shared with a particular internal or external stakeholder.

If the customer requires accounting, tax, payroll, legal, labor, compliance, audit, or other professional judgment, the customer is responsible for obtaining and relying on qualified advisors independent of GeriPay. The Service may hold operational records relevant to those domains, but it is not a substitute for the customer's own legal, tax, payroll, accounting, HR, or compliance functions.

16.5 Original-record retention, audit readiness, and evidence control

The customer is responsible for preserving original receipt images, merchant-issued records, supporting documents, independent books and records, approval materials, explanatory materials, legal-hold materials, and any other evidence the customer needs for accounting, tax, payroll, audit, dispute, litigation, employment, insurance, regulatory, or internal-governance purposes. The customer must decide what evidence is sufficient for its own needs and may need to maintain records outside the Service even where the Service stores related copies, derivatives, or workflow history.

GeriPay is not the customer's sole system of record unless GeriPay expressly agrees otherwise in a separate written agreement. The customer may not assume that every original, every supporting record, every provider-side message, every historical display state, or every legally important artifact will exist forever in exactly the form the customer would prefer. If the customer needs parallel retention, backup exports, or independent archives, that is the customer's responsibility.

16.6 Training, supervision, and internal misuse prevention

The customer is responsible for training and supervising its administrators, members, employees, contractors, consultants, and other representatives who use or influence use of the Service. This includes setting appropriate internal access controls, monitoring stale roles and stale invites, preventing shared-account practices, checking for internal impersonation or delegated-access abuse, detecting duplicate or suspicious submissions, and maintaining sufficient internal awareness to identify when approvals, visibility, payout changes, exports, or report use are occurring outside expected bounds. The customer must also maintain reasonable internal processes to reduce phishing, spoofing, social-engineering, collusion, and other misuse risks affecting the Service.

GeriPay does not become the customer's internal compliance department, fraud-review department, finance controller, or workforce training provider merely because the Service may contain logs, review states, status markers, or alert-like features. If the customer's personnel are undertrained, poorly supervised, misaligned with policy, or allowed to keep inappropriate access, the resulting harm remains customer-side harm to the fullest extent permitted by law.

16.7 Cooperation in exception, incident, and dispute handling

The customer and its relevant users must cooperate promptly, accurately, and in good faith when exceptions, anomalies, disputes, fraud concerns, security issues, provider exceptions, payment-adjacent failures, internal investigations, legal holds, subpoenas, regulatory inquiries, insurer requests, or law-enforcement matters affect the Service or records associated with the Service. That cooperation may include providing explanations, preserving materials, supplying supporting documents, confirming internal authority, identifying relevant personnel, validating whether suspicious activity was authorized, and responding within timeframes reasonably requested by GeriPay.

Failure to cooperate may impair GeriPay's ability to support the Service, contain harm, preserve evidence, or defend itself, and may justify delayed processing, narrowed support, access restrictions, preservation measures, refusal of requested action, or other protective steps. GeriPay is not obligated to resolve a dispute, reverse an action, or restore a preferred outcome while the customer withholds information, provides inconsistent explanations, or fails to preserve relevant materials.

Section 17. Prohibited Conduct

17.1 False, manipulated, forged, or misleading records

You may not use the Service to create, submit, store, organize, preserve, or circulate false, manipulated, forged, duplicated, unauthorized, misleading, or materially incomplete records. This prohibition includes fabricated receipts, altered images, doctored screenshots, composited files, cropped or context-stripped source materials, sham merchants, false dates, false totals, false taxes, false tips, false line items, false supporting explanations, false approval context, and any attempt to make a disputed or improper event appear ordinary, authentic, approved, or policy-compliant through GeriPay's workflows.

This prohibition applies whether the false or misleading conduct occurs at the source-record layer, the SmartScan or correction layer, the reimbursement layer, the payout layer, the reporting layer, the public verification layer, or the legal-acceptance and audit layer. The fact that the Service can ingest, process, display, or preserve a record does not make that record legitimate, and no person may use GeriPay as a false paper-trail engine for internal deception, outside deception, or later dispute positioning.

17.2 Impersonation, credential misuse, and authority abuse

You may not impersonate another user, administrator, approver, finance actor, support contact, provider representative, organization representative, or other person connected to the Service. You may not use stolen, borrowed, pooled, shared, compromised, misdirected, or otherwise unauthorized credentials, invite links, reset flows, recovery channels, inboxes, browsers, sessions, or devices to gain or preserve access, influence workflow outcomes, or obscure who actually acted. You may not exploit stale invites, stale roles, deactivated access, or leftover privileges after authority should have ended.

You may not claim authority you do not have, preserve authority you know you no longer have, or use delegated access, shared inboxes, or internal credential-sharing practices as a cover for unauthorized activity. Misuse that appears internally authenticated is still prohibited. GeriPay may treat such conduct as unauthorized access, fraud risk, or abuse even where a session or role looked technically valid at the time.

17.3 Reimbursement, payout, and workflow abuse

You may not use reimbursement, approval, payout-method, or payment-history workflows to inflate claims, submit duplicates, split one claim into misleading fragments, conceal conflicts, evade policy thresholds, route value to the wrong person, or otherwise misappropriate organizational funds. You may not create or exploit false approval sequences, collusive approval chains, self-approval patterns, fake exception handling, beneficiary substitutions, or destination changes intended to divert or disguise value. You may not knowingly store wrong payout details, route a payment to a straw recipient, or use repeated requests, retries, overrides, or partial events to confuse who was supposed to be paid and why.

You may not misuse operational status labels, workflow history, or payment-history records to suggest that GeriPay approved, guaranteed, authenticated, funded, or conclusively settled something that it did not. You may not use the existence of a request, approval-like state, payout-method record, or payment-history entry to manufacture false legitimacy or to pressure internal reviewers, counterparties, advisors, or outsiders into accepting a false account of what actually happened.

17.4 Sanctions-evasion, AML-adjacent concealment, bribery, and corruption

You may not use the Service in violation of sanctions restrictions, export-related restrictions, anti-corruption obligations, or similar legal limits, and you may not use the Service on behalf of, for the benefit of, or at the direction of blocked, restricted, sham, or concealed parties where prohibited by law. You may not disguise geography, ownership, beneficiary identity, merchant identity, business purpose, or transaction purpose in order to evade review or make restricted conduct look ordinary. You may not use sham vendors, sham employees, sham consultants, sham recipients, or misleading categorization to conceal unlawful or restricted conduct behind apparently normal reimbursement or report records.

You may not use the Service to document or conceal bribes, kickbacks, improper benefits, corrupt expense claims, disguised compensation, or books-and-records-style falsification. GeriPay is not a sanctions screener, AML monitor, or anti-bribery certifier, but that does not permit users to treat the Service as a neutral documentation layer for restricted, suspicious, or corrupt conduct. The absence of a block, flag, or enforcement action does not mean any conduct is lawful, compliant, or approved.

17.5 Technical abuse, automation abuse, and interference with the Service

You may not scrape non-public data, engage in credential stuffing, brute-force attacks, hostile automation, token guessing, abusive polling, workflow flooding, denial-of-service activity, malware delivery, ransomware activity, supply-chain attack behavior, adversarial prompt or input abuse, or any other technical conduct intended to bypass controls, degrade availability, alter outputs, distort logs, overwhelm review workflows, or undermine the integrity of the Service. You may not probe public verification surfaces, login flows, upload flows, reimbursement workflows, or payout-related flows in a way that is abusive, deceptive, evasive, or intended to extract data or destabilize product behavior.

You may not reverse engineer, interfere with, disable, evade, or degrade security controls, throttling, logging, telemetry, review gates, signed access paths, monitoring tools, or provider-backed protections beyond what applicable law clearly permits and these Terms expressly allow. This prohibition applies whether the attack is manual, automated, collusive, provider-assisted, or carried out through an apparently authorized account or session.

17.6 Misuse of reports, verification pages, and public-facing outputs

You may not use Reports, exports, Verified PDFs, Verification Codes, the Public Verification Page, other public or semi-public verification surfaces, screenshots, or other GeriPay-generated artifacts to deceive outsiders, create false legitimacy, manufacture a false audit trail, or overstate what GeriPay has confirmed. You may not present a verification-linked artifact as if it were an independent certification, audit opinion, legal opinion, regulator-approved record, fraud-cleared record, or guaranteed proof of entitlement, authenticity, or settlement when you know or should know that such a characterization is false or materially misleading.

You may not selectively distribute, excerpt, relabel, or context-strip product outputs to make disputed conduct appear validated by GeriPay. This includes attempts to use polished formatting, verification terminology, workflow chronology, or stored history to sanitize manipulated receipts, improper reimbursements, wrong-destination payments, or other conduct that was false, unauthorized, incomplete, or contested.

17.7 Obstruction, deletion, or distortion during review or investigation

You may not delete, alter, conceal, corrupt, rewrite, overwrite, or distort records, logs, screenshots, receipts, corrections, approval history, Payment History records, Reports, verification-linked artifacts, legal-acceptance evidence, or related materials in order to obstruct review, confuse chronology, or impair support, fraud analysis, provider inquiry, insurer review, legal process, or later dispute defense. You may not coach false narratives, selectively withhold responsive materials, pressure others to destroy or reshape evidence, or manipulate visibility settings or role assignments to obscure what happened once review has begun or is reasonably anticipated.

You may not interfere with GeriPay's monitoring, evidence preservation, provider coordination, forensic review, or legal-response work. Anti-spoliation and anti-obstruction principles apply whether the matter involves fraud, cyber compromise, internal dispute, sanctions concern, payment anomaly, public verification misuse, legal claim, or regulatory inquiry. Attempts to obstruct or distort relevant evidence may themselves be treated as independent breaches and may justify immediate restriction, preservation, disclosure, indemnity claims, or other protective action.

Section 18. Third-Party Providers, Infrastructure, and Integrated Dependencies

18.1 Provider and dependency categories

The Service depends on third-party providers and layered infrastructure for a wide range of core functions, including hosting, runtime and compute capacity, database services, storage, file delivery, email and message delivery, SmartScan and automated processing, security tooling, monitoring, routing, verification support, payout-adjacent workflows, and other technical or operational capabilities. That provider involvement is a normal part of how the Service operates. It does not mean GeriPay controls every detail of the provider's behavior, internal systems, regions, security posture, retention practices, incident handling, or continuity outcomes.

Provider categories matter more than any single present-tense vendor label in these Terms. GeriPay may rely on current providers, replacement providers, additional providers, or layered subprocessor chains over time. No customer should assume that the Service is insulated from provider limitations merely because the Service is branded as GeriPay or because the provider is commercially recognized.

18.2 Provider substitution, addition, and removal

GeriPay may add, remove, replace, reconfigure, or otherwise change providers, provider categories, technical pathways, provider regions, model paths, APIs, hosting arrangements, file-delivery arrangements, and comparable dependencies at any time for operational, legal, security, commercial, performance, continuity, or support reasons. Provider change may occur because a provider changes its own rules, features, prices, regions, quotas, availability, security posture, compliance posture, or business viability, or because GeriPay decides another path is more appropriate.

No current or former provider relationship creates a promise that the same vendor, model, region, API, or infrastructure path will remain in place indefinitely. Customers do not receive a contractual right to demand continued use of any particular provider, any particular route to a provider, or any particular provider-backed behavior merely because the Service used it previously or because an internal product behavior appeared to depend on it at one time.

18.3 Provider-side acts, omissions, policies, and changes

Providers may experience outages, degraded service, partial failures, policy changes, model changes, retention changes, pricing changes, feature deprecation, account restrictions, regional changes, routing changes, security incidents, insider misuse, support delays, restore failures, or other operational or legal changes that affect the Service. Those events may alter SmartScan behavior, report availability, public verification behavior, email delivery, file access, payout-adjacent signaling, response timing, or other user-visible and admin-visible product behavior.

GeriPay may not know every provider-side fact immediately, may receive incomplete or evolving provider information, and may later learn that a provider-side issue was broader, narrower, earlier, later, or technically different than first understood. GeriPay is not required to treat provider marketing, provider architecture descriptions, or provider incident communications as guarantees owed by GeriPay to the customer.

18.4 Cloud, storage, region, and routing realities

The Service may depend on cloud and storage systems that operate through one or more primary regions, replication layers, backup layers, archival layers, CDN-like delivery layers, signed-access paths, and dynamic routing or rerouting behaviors. Storage-backed files, previews, Verified PDFs, public verification assets, logs, workflow metadata, and structured records may therefore be affected by region choice, region mismatch, replication lag, object-store drift, stale metadata, restore gaps, delivery-layer caching, DNS or certificate issues, or changes in how traffic is routed through provider infrastructure.

Nothing in these Terms guarantees a particular region, a particular routing path, a particular failover behavior, perfect geographic consistency, perfect object persistence, or perfect restoration of every file, preview, artifact, or metadata record. Database and storage continuity are not the same thing, and object restoration, backup restoration, record restoration, and signed-access continuity may diverge. Customers must not assume that a cloud-backed stack or signed-access system guarantees perfect availability, perfect deletion, or perfect recovery.

18.5 AI vendors, model changes, and extraction-provider dependencies

SmartScan and related automated-processing features may depend on AI vendors, OCR providers, inference systems, prompt logic, model-specific behavior, preprocessing layers, rate limits, and provider-side safety, retention, logging, and routing policies that can change over time. Similar inputs may yield different outputs across time or providers, and a provider or model change may alter output quality, field structure, confidence, latency, failure modes, or supportability without preserving the exact behavior users previously observed.

GeriPay does not guarantee that any one AI provider, model family, inference pathway, prompt pattern, or provider-side policy will remain available, unchanged, or suitable for the customer's preferred use. Provider-backed automated processing may be interrupted, narrowed, degraded, delayed, or replaced, and GeriPay does not guarantee provider-side retention outcomes, regional processing behavior, internal provider controls, or static extraction performance merely because the Service presently uses AI-assisted processing in one or more areas.

18.6 Payment-adjacent providers, banks, and downstream actors

Payment-history and payout-adjacent functions may depend on processors, banks, payout rails, financial-institution-connected providers, compliance-review systems, intermediaries, and other downstream actors outside GeriPay's control. Holds, unsupported corridors, route failures, account restrictions, beneficiary mismatches, returns, reversals, bank release delays, callbacks, compliance reviews, or similar downstream events may affect both actual payment outcomes and the visibility of those outcomes inside the Service.

GeriPay is not the downstream institution, does not control the downstream actor's legal or operational decisions, and does not assume the downstream actor's obligations merely because the Service may record or display payout-adjacent data. Provider involvement at the payment-adjacent layer does not convert GeriPay into a bank, payor, money transmitter, settlement service, or guarantor of payment completion.

18.7 No special warranty from provider selection

The use of commercially known or technically sophisticated providers does not create a warranty by GeriPay of security, uptime, legality, continuity, region stability, output quality, fraud prevention, email delivery, payment success, recoverability, or incident-free operation. Customers may not infer that a provider-backed feature is safer, more final, more accurate, more durable, or more suitable for special reliance merely because the underlying provider is large, popular, or technically advanced.

Provider selection is not an invitation to brand-name reliance. GeriPay may use strong providers and still face outages, degraded service, provider-side incidents, misconfiguration, storage gaps, missing callbacks, partial restores, routing problems, output drift, or incomplete incident facts. Later warranty, liability, indemnity, and dispute sections should be read in light of this provider-boundary rule.

Section 19. Security, Availability, Cyber Events, and Service Changes

19.1 High-level security posture without operational overcommitment

GeriPay may use administrative, technical, organizational, operational, and provider-supported measures intended to support the security, integrity, resilience, and defensibility of the Service. Those measures may change over time as threats, vendors, workflows, regulations, and product architecture evolve. GeriPay is not required to freeze the Service around one static security design or one fixed published control list, and no customer should treat any high-level description of safeguards as a complete or permanently current inventory of every control actually in use.

The existence of safeguards is important, but it should not be overread as a guarantee that every account, upload, report, payout-related record, public verification surface, or provider-backed dependency will remain perfectly protected. Security posture in a system like GeriPay is necessarily evolving, layered, and partly dependent on customer behavior and provider behavior that GeriPay does not fully control.

19.2 No perfect security, no perfect detection, and no perfect availability

No service, system, workflow, cloud stack, public page, signed file path, email flow, AI-assisted process, or provider chain is perfectly secure, uninterrupted, private, error-free, current, or available. GeriPay does not promise perfect prevention, perfect detection, perfect classification, perfect containment, perfect remediation, perfect restoration, perfect transparency, perfect chronology, or perfect availability. Threats can be external, internal, collusive, automated, or provider-linked, and some will remain ambiguous, partially visible, or only fully understood after the most important decisions have already been made.

This no-perfect-security and no-perfect-availability rule is central to these Terms. A serious stack, a polished product, strong providers, logs, alerts, and protective measures do not create a warranty that compromise will not occur, that every compromise will be detected immediately, that every outage will be brief, or that every damaged or missing record will be fully restored in the precise form a customer prefers.

19.3 Threat categories and risk examples

Threats and harmful events may include account takeover, phishing, spoofing, password reuse, credential stuffing, session theft, inbox compromise, browser compromise, malicious extensions, malware, ransomware, destructive automation, insider misuse, stale-access abuse, supply-chain compromise, provider compromise, callback failure, API misuse, data corruption, object-store loss, routing failure, DNS or certificate issues, infrastructure degradation, legal or sanctions holds, support-system abuse, and mixed human-and-technical incidents that do not fit neatly into one category at the outset.

Those threats may affect different product surfaces differently. Some may target login and onboarding. Some may target uploads and SmartScan. Some may target reimbursement approvals, payout-destination changes, Payment History, Reports, Verified PDFs, public verification, legal-acceptance evidence, or preserved logs. The fact that one surface remains usable does not mean all related surfaces remain trustworthy or unaffected.

19.4 Provider-caused and provider-dependent incidents

Some incidents may originate with, depend on, or be materially worsened by third-party providers, infrastructure vendors, storage providers, email providers, AI vendors, monitoring vendors, payout-adjacent providers, banks, or subprocessor chains. Provider-side misconduct, misconfiguration, compromised credentials, insider misuse, policy changes, region-level failures, restore failures, rate limits, account restrictions, or evolving incident facts may affect what GeriPay can see, what GeriPay can preserve, how quickly GeriPay can respond, and how quickly GeriPay can communicate reliable conclusions.

Provider-dependent incidents are especially likely to produce incomplete, delayed, or revised factual pictures. GeriPay may receive partial telemetry, delayed alerts, evolving provider statements, or revised timelines, and it may need to take protective action before every provider-side fact is settled. Customers may not assume that early incident descriptions will be complete, final, or perfectly categorized.

19.5 Maintenance, outages, degraded performance, and emergency action

The Service may experience planned maintenance, unplanned outages, degraded performance, partial failure, delayed callbacks, frozen workflows, restricted uploads, report-generation delays, public verification interruptions, signed-access failures, payout-adjacent disruption, or other continuity issues. Some failures will be total, some will be partial, and some will affect only a narrow but important surface such as legal notices, file previews, SmartScan, public verification, or email-dependent flows. GeriPay may take emergency action to contain harm, preserve evidence, reduce abuse, reroute traffic, freeze high-risk actions, narrow features, or temporarily disable parts of the Service.

GeriPay does not guarantee immediate restoration, identical restoration, or customer-preferred restoration order. It may prioritize containment, evidence preservation, legal risk, or platform stability over speed, convenience, feature completeness, or perfect continuity of every workflow. Emergency measures may inconvenience users and organizations, but they may still be necessary and reasonable under the circumstances.

19.6 Data integrity, corruption, backup, and restoration limits

Records, files, previews, logs, metadata, reimbursement history, payout-related history, public verification artifacts, and other Service materials may be corrupted, mismatched, delayed, partially restored, incompletely replicated, or irretrievably lost because of software defects, provider failures, object-store issues, restore gaps, concurrency problems, support mistakes, attack activity, or other destructive events. Backup and archival systems may preserve some layers and not others. Structured records may survive where files do not, and files may survive where supporting metadata, previews, or chronology do not.

Recovery may therefore be partial, delayed, expensive, imperfect, or impossible in some circumstances. GeriPay does not guarantee that every receipt image, every report artifact, every signed access path, every log event, every workflow state, every version, or every derived record will always be recoverable or recoverable in the exact order, format, or relationship previously visible to the customer.

19.7 Remediation rights and no duty to disclose every investigative detail

GeriPay may investigate, isolate, preserve, throttle, lock, revoke, challenge, rotate, disable, reroute, reconfigure, patch, restore, regenerate, replace, or otherwise remediate systems, records, sessions, flows, and dependencies in response to actual or suspected risk. Those actions may be taken without customer approval and may be taken based on incomplete information, evolving incident facts, reasonable suspicion, provider alerts, or legal or support considerations. Customers do not have a veto over containment, remediation, evidence-preservation, or emergency design decisions reasonably taken to protect the Service.

GeriPay is also not required to disclose every fraud signal, every security rule, every provider detail, every forensic method, every preservation step, or every investigative hypothesis while a matter is still being reviewed or where disclosure could increase risk, violate law, impair defense, or compromise later enforcement. Confidentiality around methods and incomplete facts is part of reasonable incident handling, not evidence that an issue is being ignored.

19.8 Service redesign and security-driven product changes

GeriPay may redesign workflows, remove or narrow risky features, change SmartScan behavior, change provider-backed paths, alter upload handling, change visibility rules, challenge or slow previously easy actions, replace models, adjust report or verification behavior, or otherwise modify the Service for security, fraud prevention, provider dependence, compliance, support, continuity, or operational reasons. The product is not promised in a frozen state, and no customer should rely on the permanent availability of a particular workflow sequence, approval path, export pattern, or public verification behavior.

Security-driven or risk-driven changes may occur quickly, may be partial, and may prioritize defensibility or platform integrity over user preference, backward familiarity, or feature continuity. GeriPay does not guarantee that every change will preserve the exact same behavior, outputs, timing, or user expectations that existed before the change.

Section 20. Privacy Policy and Related Policies

20.1 Privacy Policy incorporation and separate function

The Privacy Policy made available through the Service, including at the legal page or successor location designated by GeriPay, is incorporated by reference into the broader legal framework governing use of the Service. The Privacy Policy is intended to describe how GeriPay handles information, including categories of information, processing contexts, role framing, disclosure paths, provider-supported processing, retention realities, incident posture, and privacy-rights handling. You and, where applicable, your organization are responsible for reviewing the Privacy Policy before using the Service, completing a legal-acceptance flow, or continuing use after an update where review is reasonably made available. The fact that the Privacy Policy is incorporated does not mean it performs the same legal function as every other part of these Terms.

These Terms govern contract formation, eligibility, authority, access, permitted use, responsibility allocation, role disclaimers, anti-reliance rules, warranty disclaimers, liability limitations, indemnity, dispute handling, and other risk-allocation questions. The Privacy Policy governs disclosure about information handling and privacy-governance mechanics. The two documents should be interpreted consistently where possible, but the Privacy Policy does not by itself expand GeriPay's role, create a fiduciary or regulated-services undertaking, eliminate the disclaimers and allocation rules in these Terms, or create liability, accuracy, payment, compliance, security, or outsider-reliance guarantees unless GeriPay expressly says so in a separate controlling writing. If a direct conflict arises, the allocation rule stated in Section 1.6 applies, and questions of information handling and privacy disclosure should be read through the Privacy Policy while questions of contract scope, use restrictions, warranties, liability, and disputes remain governed by these Terms unless an applicable law requires a narrower result.

20.2 Supplemental operational and security policies

GeriPay may publish, present, or otherwise maintain supplemental operational, security, feature-specific, or product-governance materials that sit alongside these Terms and the Privacy Policy. These materials may include acceptable-use rules, upload instructions, SmartScan review guidance, reimbursement workflow guidance, payout-method instructions, report legends, public-verification messaging, account or security notices, support procedures, status explanations, provider or continuity notices, implementation guides, onboarding materials, or other feature-level explanations and requirements. Some of those materials may be expressly designated as binding supplements or prerequisites for using a particular feature, workflow, or access path, and GeriPay may condition access to a feature or workflow on compliance with them.

At the same time, not every operational or explanatory material is intended to operate as an independently negotiated contract term or as a freestanding warranty. GeriPay may use short-form instructions, warnings, examples, legends, prompts, or feature descriptions to explain how a workflow generally operates without promising that the workflow will always behave the same way, produce the same result, satisfy every internal customer policy, or remain immune from provider, legal, or factual variation. Unless GeriPay expressly states that a particular supplement controls, these Terms and the Privacy Policy remain the main governing documents, and no operational guide, feature legend, support shorthand, or instructional material should be treated as silently overriding the contract architecture or creating a broader promise than these Terms actually make.

20.3 Customer responsibilities under other applicable documents

You and your organization may be subject to internal rules, reimbursement policies, accounting rules, tax rules, payroll or employment rules, document-retention policies, procurement obligations, confidentiality obligations, industry requirements, regulatory frameworks, collective or workplace rules, or separate contracts with employees, contractors, recipients, counterparties, banks, auditors, regulators, insurers, or other third parties. Those outside documents and obligations may affect what you upload, what you approve, what you reimburse, what reports you generate or share, how long you retain records, and what internal controls or disclosures you must maintain. Those obligations remain your responsibility. GeriPay does not agree, merely by providing the Service, to learn, map, enforce, or continuously adapt every workflow to every outside document that may apply to a customer's internal environment.

Accordingly, the customer remains responsible for deciding whether and how the Service fits with its own internal governance and outside obligations. The existence of a field, workflow, status label, report, payout-related view, verification feature, or support step does not mean GeriPay has confirmed that use of that feature will satisfy the customer's internal policy or any outside legal, accounting, tax, payroll, audit, employment, or contractual requirement. If your internal rules or outside obligations call for more review, different approval paths, narrower sharing, longer retention, or additional legal or professional advice, you are responsible for implementing those measures yourself and for not overreading the Service as a substitute for those independent controls or advisors.

20.4 Updates, notices, and cross-reference hygiene

GeriPay may update the Privacy Policy and other related legal or operational notices as the Service, provider landscape, legal environment, security posture, feature set, and workflow architecture evolve. Those updates may occur on a schedule different from updates to these Terms and may follow their own notice, acknowledgment, or legal-effect mechanics to the extent permitted by law and described in the applicable document. Some changes may be communicated through posted updates, account notices, email, in-product presentation, public legal pages, updated acceptance flows, or other channels GeriPay reasonably selects. Some changes may require fresh assent, renewed review, or a new electronic-acceptance event. Other changes may become effective through notice and later continued use where law allows. GeriPay may preserve legal-acceptance evidence, version history, archived copies, and related chronology showing what document was presented, when it was presented, and what later version or notice path applied.

References in these Terms to the Privacy Policy, notices, warnings, feature legends, or related legal materials should be read with cross-reference hygiene in mind. The relevant document is ordinarily the then-current applicable version, except where a preserved historical version tied to a specific acceptance event, dispute, incident, or legal question is the relevant version for that earlier event. Older screenshots, cached pages, copied excerpts, prior drafts, support quotations, informal summaries, or third-party descriptions do not control over the operative legal text reflected in the preserved governing documents and related legal-acceptance evidence. GeriPay may also correct broken references, move legal pages, reformat documents, or maintain archived copies without changing the substantive allocation built into these Terms unless the updated text itself materially says otherwise.

20.5 Non-contractual support content and training materials

Help-center articles, onboarding guides, FAQs, training materials, release notes, examples, templates, screenshots, walkthroughs, benchmark explanations, support responses, troubleshooting messages, public-facing descriptions, and similar content may explain how features generally work, how a user may navigate a flow, or how GeriPay currently expects a workflow to behave under ordinary conditions. That content can be useful, but it is often simplified, abbreviated, context-specific, quickly prepared, or directed at a particular issue rather than written as full legal text. It may also lag behind later provider, security, product, or policy changes. For that reason, such materials should be read as operational or educational content unless GeriPay expressly designates them as controlling legal terms.

No help article, support email, chat response, training note, implementation suggestion, public-facing feature description, or similar material creates an independent warranty, regulatory undertaking, approval commitment, payment commitment, security guarantee, provider-performance guarantee, legal-compliance guarantee, or promise that the Service will remain static or suitable for every purpose. If such materials are inconsistent with these Terms, the Privacy Policy, or another expressly controlling signed writing, the governing legal documents control. The customer remains responsible for obtaining independent legal, accounting, tax, payroll, compliance, security, or other professional guidance where needed rather than treating support or educational content from GeriPay as a substitute for those independent judgments.

Section 21. Monitoring, Investigations, Evidence Preservation, and Legal Process

21.1 Monitoring rights but not continuous monitoring duties

GeriPay may monitor access, usage, logs, metadata, workflow chronology, reports, public verification activity, payout-method changes, fraud signals, support activity, legal-acceptance evidence, and other operational data for security, support, abuse detection, quality, integrity, legal, insurance, auditability, and dispute-defense purposes. Monitoring may be manual, automated, provider-supported, event-triggered, periodic, or continuous for selected surfaces, and it may cover authenticated and relevant public-facing surfaces when necessary to understand or protect the Service.

These rights do not create a duty to monitor every customer action continuously, detect every issue before harm occurs, classify every anomaly correctly in real time, or provide constant human review. The existence of monitoring is a protective and defensive right, not a guarantee of complete policing. GeriPay may decide what to monitor, when to monitor it, and how deeply to review it based on product needs, risk signals, and available resources.

21.2 Investigation triggers and review methods

GeriPay may open or expand review when it detects or reasonably suspects suspicious activity, fraud indicators, impersonation, account compromise, false records, duplicate or manipulated submissions, authority conflicts, beneficiary disputes, provider anomalies, cyber incidents, legal claims, insurer inquiries, regulator contact, law-enforcement contact, public verification misuse, or other events suggesting that deeper review is warranted. GeriPay may act on anomaly signals, internal reports, customer complaints, provider-supplied information, outside complaints, preserved chronology, or partially developed facts without waiting for final proof from outside parties.

Review methods may include manual examination, automated correlation, chronology review, log review, metadata review, cross-record comparison, provider coordination, file review, support-history review, session review, legal-acceptance review, and other reasonable technical or operational steps. GeriPay may investigate across account, workspace, upload, SmartScan, reimbursement, payout, report, verification, support, and legal-history surfaces as reasonably necessary to understand what happened and to protect the Service.

21.3 Evidence preservation, holds, and anti-spoliation posture

GeriPay may preserve records, freeze deletion, maintain archived or duplicated copies, place fraud holds, place dispute holds, place legal holds, preserve logs, preserve legal-acceptance evidence, preserve provider communications, preserve report artifacts, preserve public-verification-related records, or otherwise retain relevant materials when GeriPay reasonably believes preservation is warranted for fraud review, cyber response, support, insurance, auditability, legal defense, regulatory response, or anticipated legal process. Preservation may cover both customer-visible and non-customer-visible artifacts and may continue after ordinary workflow use has ended.

Preservation may occur without advance notice and may override ordinary deletion expectations to the extent reasonably necessary and permitted by law. A preserved artifact may remain inaccessible to the customer, may remain only in internal or provider-backed form, or may be preserved in a state that is useful for evidentiary purposes rather than customer convenience. No person may assume that because a workflow is closed, a user is deactivated, or a file is no longer ordinarily visible, GeriPay has surrendered its right to keep and later rely on preserved evidence.

21.4 Provider, expert, insurer, and advisor coordination

GeriPay may coordinate with providers, consultants, advisors, outside counsel, forensic experts, auditors, insurers, payment-adjacent partners, cloud or storage providers, AI providers, security vendors, and similar parties when investigating incidents, preserving evidence, defending claims, responding to legal process, restoring systems, or evaluating what happened. Such coordination may require GeriPay to disclose relevant records, metadata, chronology, files, or technical details to those parties on a need-to-know basis and subject to appropriate confidentiality, legal, insurance, or operational constraints.

This coordination right does not mean GeriPay is making broad public disclosures, and it does not require GeriPay to share the same information equally with the customer at the same time. Some supporting parties may receive information because they are needed to investigate, remediate, insure, defend, or respond to a matter even when full disclosure to the customer would be premature, unsafe, legally restricted, or strategically inappropriate.

21.5 Law-enforcement, regulatory, and civil-process response

GeriPay may respond to subpoenas, court orders, warrants, preservation demands, law-enforcement requests, regulator inquiries, insurer requests, civil discovery, governmental directives, and other legal process relating to the Service or records associated with the Service. GeriPay may preserve, review, disclose, withhold, narrow, object to, negotiate, sequence, or otherwise manage its response as it considers appropriate or as law requires. GeriPay may also decide whether, when, and how to give notice to a customer or user where notice is not legally prohibited but is still subject to strategic, safety, or operational considerations.

GeriPay is not required to provide advance notice in every case, is not required to challenge every request, and is not required to delay response until the customer is satisfied. Legal-process timing, scope, and objection posture may depend on law, urgency, preservation needs, risk to others, investigative secrecy, insurance obligations, or provider coordination realities. The customer remains responsible for its own legal and regulatory obligations and for obtaining its own counsel where needed.

21.6 Customer cooperation and document-production duties

Users and organizations must cooperate promptly, accurately, and in good faith when GeriPay requests information, confirmations, supporting materials, preserved records, chronology explanations, authority confirmations, beneficiary confirmations, internal-policy context, device or account context, or other reasonably relevant material during review, investigation, support, fraud analysis, cyber response, legal process, or dispute defense. This duty includes preserving relevant materials under the customer's control, identifying responsible personnel, clarifying who acted and why, and correcting materially incomplete or misleading submissions previously given to GeriPay.

If cooperation is lacking, delayed, contradictory, or strategically incomplete, GeriPay may narrow support, delay requested actions, maintain holds, maintain restrictions, refuse restorations, preserve broader records, or otherwise protect itself and the Service. To the fullest extent permitted by law, the customer may bear the consequences and reasonable costs associated with non-cooperation, including worsened harm, impaired defense, longer incident handling, or broader preservation measures.

21.7 Confidentiality of investigative methods and partial-facts reality

GeriPay may limit what it shares about investigative methods, detection logic, provider findings, fraud signals, security controls, preservation tactics, legal strategy, or other sensitive review details while a matter is being investigated or where disclosure could increase risk, compromise security, undermine provider coordination, prejudice legal positions, or violate law or confidentiality obligations. Customers may therefore receive partial facts, preliminary facts, evolving facts, or corrected facts over time rather than one complete and final narrative at the first communication.

This partial-facts reality is not evidence of waiver, bad faith, or indifference. In complex matters, facts may be delayed, revised, reclassified, or technically ambiguous for a substantial period. GeriPay may update, correct, narrow, or expand its prior statements as additional information becomes available, and no customer should rely on the earliest available statement as if it were guaranteed to remain complete or final.

21.8 No obligation to pursue every claim or provide every remedy

GeriPay may decide, in its sole reasonable discretion, how aggressively to investigate, escalate, preserve, disclose, suspend, litigate, negotiate, or otherwise pursue a given issue. Not every suspicious event will result in a full forensic investigation, full disclosure to every affected person, formal escalation to authorities, full recovery effort, or aggressive pursuit of every available remedy. GeriPay may choose partial action, staged action, delayed action, quiet preservation, confidential provider coordination, business resolution, or no further action at all depending on the facts, costs, legal constraints, risk, and strategic needs involved.

Limited action, delayed action, informal action, or no action in one instance does not waive GeriPay's rights in another instance and does not endorse, excuse, or legitimize the conduct at issue. No customer or user may argue that because GeriPay did not pursue every claim, disclose every suspicion, or exhaust every possible remedy, GeriPay accepted the conduct, validated the records, or surrendered its later contractual or legal rights.

21.9 Use of preserved records for enforcement and defense

GeriPay may use preserved records, legal-acceptance evidence, workflow chronology, reports, verification-linked artifacts, logs, technical metadata, provider communications, and related materials to enforce these Terms and related policies, respond to complaints, answer audits or investigations, address reimbursement or payout disputes, support insurer or provider response, and defend claims involving the Service or records associated with the Service. Where appropriate, GeriPay may also use such materials to defend its providers, advisors, or affected organizations when the underlying matter arises from customer-side conduct, disputed workflow history, suspected misuse, or a preserved operational record.

No preserved record must be favorable to the customer in order for GeriPay to rely on it. Preserved materials may reflect conflicting facts, disputed chronology, partial provider information, or mixed evidence. The fact that a preserved record is incomplete, inconvenient, or unfavorable to the customer does not bar GeriPay from using the categories of evidence that remain available to support enforcement, defense, investigation, preservation, or response decisions.

Section 22. Suspension, Refusal of Service, and Termination

22.1 Refusal of onboarding or continued access

GeriPay may refuse onboarding, invite acceptance, account activation, role assignment, workspace participation, feature access, public-artifact access, or continued use of the Service at any time, in whole or in part, based on legal, fraud, abuse, authority, operational, provider, security, reputational, or policy concerns, including where facts are incomplete, evolving, or disputed. Starting a signup flow, receiving an invite, appearing in a workspace, or previously using the Service does not create an entitlement to initial or continuing access.

GeriPay is not required to explain every refusal decision in full, to disclose every risk signal or investigative method, or to provide advance notice before refusing or narrowing access where doing so would be impractical, unsafe, legally risky, or inconsistent with evidence-preservation or provider-response needs. A refusal decision may rest on one issue, multiple issues, or an overall unacceptable risk posture that does not require final adjudication before GeriPay acts.

22.2 Temporary restrictions, freezes, and emergency suspensions

Instead of, or in addition to, full termination, GeriPay may impose temporary or indefinite restrictions, including read-only states, session revocation, forced reauthentication, upload freezes, SmartScan restrictions, reimbursement holds, payout-method freezes, payment-history visibility limits, report-generation holds, verified-PDF restrictions, verification-code disablement, public-verification changes, support-channel narrowing, or other targeted controls. GeriPay may use these narrower measures to contain harm, preserve evidence, await provider input, respond to legal process, or limit risk while additional facts are developed.

Emergency controls may be imposed without prior notice and without a final determination that misconduct occurred. A temporary measure does not waive GeriPay's right to escalate later to broader suspension or termination, and the choice to leave one feature available does not create a promise that the rest of the Service will remain available. Protective freezes and containment steps are ordinary risk-management tools within the Service, not admissions that GeriPay owes restoration, explanation, or compensation.

22.3 Account, user, organization, and feature-level termination paths

Termination or restriction may apply at many different levels, including a single user, a single role, a single workspace, a single organization, a single feature, a single public artifact, or the entire Service relationship. GeriPay may deactivate a member, remove a user from an organization-facing workspace, revoke admin authority, disable a public verification surface, shut off report generation, revoke signed access, or terminate all access associated with an organization or related set of accounts. These are distinct control scopes, and GeriPay may choose the level it believes is appropriate under the circumstances.

Cutting off access does not necessarily erase historical records, disable every derivative artifact, or unwind every prior workflow effect. A user may lose Workspace access while preserved logs, legal-acceptance evidence, receipts, reimbursement history, payout-related records, Reports, or public verification-linked artifacts remain stored, preserved, or otherwise relevant. Access rights, historical records, public-surface handling, and preservation obligations are separate issues, and GeriPay may treat them separately.

22.4 Termination triggers and discretionary grounds

Grounds for restriction, suspension, or termination may include breach of these Terms, false or manipulated records, fraud risk, impersonation, stale or disputed authority, account compromise, technical abuse, sanctions or corruption concerns, suspicious reimbursement or payout behavior, public-verification misuse, repeated policy evasion, provider-imposed restrictions, legal-process pressure, unresolved security incidents, evidence-tampering concerns, failure to cooperate in review, or any other circumstance that creates material operational, legal, reputational, or integrity risk for GeriPay, its providers, other customers, or the public. The list is illustrative, not exhaustive.

GeriPay does not need a criminal conviction, regulatory finding, judicial determination, or internally complete factual record before acting. A reasonable risk-based decision may be made on partial facts, conflicting evidence, provider alerts, chronology anomalies, or an overall pattern that GeriPay considers unsafe or unacceptable. Continued use of the Service is conditional, and GeriPay may discontinue that access when continued operation would expose GeriPay or others to unreasonable risk.

22.5 Effect on records, outputs, public artifacts, and access after cutoff

After restriction, suspension, or termination, GeriPay may disable access to receipts, SmartScan drafts, saved records, reimbursement requests, payout methods, Payment History views, Reports, downloads, Verified PDFs, Verification Codes, the Public Verification Page, other public or semi-public verification surfaces, support interfaces, and other Service surfaces, or may leave some of those records or artifacts preserved while disabling the customer-facing ability to reach them. GeriPay may quarantine records, preserve them in evidence-oriented storage, remove public visibility, maintain public visibility for a limited purpose, or change how a previously generated artifact is delivered, displayed, or withheld.

GeriPay is not required to keep every workflow open long enough for the customer to resolve its preferred internal issue, to provide a comprehensive export at the moment of cutoff, or to preserve the prior user experience after access ends. Some artifacts may remain visible outside the terminated account's control, some may be disabled quickly, and some may survive only as preserved evidence or archived records. The customer remains responsible for its own external recordkeeping and should not treat continued access to GeriPay as guaranteed storage or guaranteed exit support.

22.6 Surviving rights, preserved evidence, and retained copies

Restriction, suspension, or termination does not erase accrued rights, accrued claims, preserved logs, audit trails, legal-acceptance evidence, investigation files, reimbursement histories, payout-related chronology, Reports, verification-linked artifacts, backups, archives, or other records GeriPay may lawfully retain. GeriPay may preserve those materials for fraud review, incident response, insurance matters, internal governance, regulatory response, arbitration, court support, or other legal or defensible operational purposes even after the underlying account, role, or Workspace is no longer active.

The customer may not treat termination as a reset button that erases past conduct, past assent, past preservation duties, or GeriPay's ability to rely on retained evidence later. Historical copies, backups, archives, preserved files, and dispute-oriented evidence sets may outlast ordinary access and may continue to exist even if the user-facing record set is narrowed, hidden, or otherwise changed after cutoff.

22.7 Restoration, reinstatement, and no reinstatement guarantee

GeriPay may deny restoration or reinstatement entirely, may make it conditional, or may restore only a narrower set of features, roles, or records than previously existed. Conditions may include identity verification, authority confirmation, explanation of suspicious events, proof of remediation, provider clearance, beneficiary re-validation, internal-control changes, preservation of relevant evidence, or other steps GeriPay reasonably requests before restoring access. No person or organization is entitled to reinstatement merely because an incident appears to have cooled, an internal dispute appears resolved, or the customer prefers renewed access.

If GeriPay does restore access, GeriPay does not promise to recreate the exact prior state. Sessions may remain revoked, tokens may remain invalid, reports or public artifacts may remain disabled, workflow history may remain preserved in a disputed or restricted state, and some records may remain unavailable, archived, or subject to continuing legal or investigative controls. Restoration, if any, may therefore be partial, delayed, conditional, and materially different from the pre-cutoff environment.

22.8 Post-termination obligations and continuing restrictions

After access ends, all surviving duties in these Terms remain in force, including duties relating to evidence preservation, confidentiality where applicable, intellectual-property limits, dispute-control provisions, indemnity, liability protections, anti-circumvention, and cooperation with investigations or legal process. Termination does not authorize the customer or its users to repurpose screenshots, download artifacts, verification materials, preserved records, or internal chronology in a misleading or retaliatory way, and it does not end duties to preserve responsive information once a dispute, investigation, or legal hold is pending or reasonably anticipated.

No terminated or suspended party may re-enter the Service through alternate accounts, alternate invites, related organizations, delegated access, shared credentials, sham identities, or affiliated actors used as stand-ins. GeriPay may treat such behavior as an independent breach and may broaden restrictions accordingly. Post-termination misuse, evasion, or evidence interference may support further preservation, disclosure, indemnity, and legal claims by GeriPay to the fullest extent permitted by law.

Section 23. Intellectual Property, Feedback, and Brand Features

23.1 Ownership of the Service and related materials

As between the customer and GeriPay, GeriPay and its licensors retain all right, title, and interest in and to the Service and the non-customer-owned materials used to create, operate, present, and support it. This includes the software, interfaces, page layouts, workflow logic, prompts, model-orchestration choices, extraction and normalization methods, databases and schema design, visual design, report and verification presentation layers, documentation, templates, support materials, branding, trademarks, service names, logos, trade dress, know-how, and other Service Materials, together with all related intellectual-property and proprietary rights. Except for customer data and other rights expressly reserved to the customer under these Terms, no ownership interest in the Service or its underlying materials is transferred to any user or organization by account creation, invitation acceptance, payment of fees, use of the Service, generation of an output, or preservation of a record inside the Service.

The fact that GeriPay may store, display, process, preserve, or generate records that incorporate customer-linked information does not change that ownership boundary. A saved receipt record, SmartScan output, Report, Verified PDF, Verification Code, artifact displayed through the Public Verification Page, support artifact, legal-acceptance evidence package, or other Service-generated artifact may reflect both customer-linked content and GeriPay-owned service structure at the same time. Customer rights in the underlying business records do not create ownership in GeriPay's software, templates, layouts, workflow states, extraction logic, verification architecture, or other Service Materials, and GeriPay's ownership of those Service Materials does not give GeriPay ownership of the Customer's underlying source records beyond the rights expressly granted elsewhere in these Terms.

23.2 Limited license to access and use the Service

Subject to these Terms and any applicable written commercial arrangement, GeriPay grants the customer and its authorized users a limited, non-exclusive, non-transferable, non-sublicensable, revocable right to access and use the Service solely for the customer's internal business use and only in the manner the Service then permits. This license is limited by role, workspace configuration, feature availability, technical restrictions, legal restrictions, commercial scope, and any suspension, investigation, security, fraud, or termination measures GeriPay lawfully applies. The license does not include any right to receive source code, obtain a copy of the underlying software stack, continue using retired features, insist on compatibility with the customer's preferred systems, or treat temporary access to a feature or artifact as a perpetual license to that feature or artifact.

Any right to download, export, print, or share records or generated outputs through the Service exists only to the extent the product then permits and these Terms allow. That practical ability does not transfer ownership of the Service layer, does not create a resale or distribution license in GeriPay's Service Materials, and does not survive suspension or termination except to the limited extent already reflected in preserved artifacts lawfully retained outside the Service or otherwise required by law. All rights not expressly granted in these Terms are reserved by GeriPay and its licensors, and no license should be implied from silence, access, support conduct, technical interoperability, or past product behavior.

23.3 Restrictions on copying, reverse engineering, extraction, and misuse

Except to the limited extent non-waivable law expressly permits otherwise, you may not copy, reproduce, republish, mirror, frame, translate, adapt, modify, create derivative works from, decompile, disassemble, reverse engineer, attempt to derive source code from, scrape, harvest, bulk extract, benchmark for publication, rent, lease, sell, resell, white-label, sublicense, or otherwise exploit the Service or Service Materials beyond the limited access rights granted in these Terms. You may not use bots, crawlers, automated extraction tools, or other automated means to collect Service Materials, public verification-page content, report layouts, verification behavior, screenshots, or other product-output patterns in order to build a competing product, train another service, reproduce GeriPay's workflows, evade restrictions, or misappropriate GeriPay's proprietary methods. You may not remove notices, obscure origin markers, defeat technical limits, bypass access controls, or use the Service in a way that misappropriates its design, functionality, or underlying business logic.

These restrictions apply even if the relevant Service surface is outward-facing, shareable, embeddable by customer action, or accessible through the Public Verification Page, another public or semi-public verification surface, or a distributed artifact. The fact that a page, Report, or verification-linked artifact can be viewed does not mean GeriPay has granted a general right to systematically copy its presentation, reuse its branding, harvest its contents at scale, or treat its visible structure as unprotected. This subsection should be read together with the prohibited-conduct, security, and public-verification sections rather than as a narrow stand-alone anti-copying clause. If applicable law grants a specific reverse-engineering, interoperability, or open-source right that cannot lawfully be disclaimed, that right is preserved only to the minimum extent required by that law.

23.4 Feedback, suggestions, and improvement rights

If you or your users send GeriPay feedback, suggestions, ideas, comments, bug reports, test results, support observations, workflow suggestions, feature requests, improvement proposals, annotations, or other similar communications about the Service, GeriPay may use, evaluate, copy, adapt, disclose, incorporate, commercialize, and otherwise act on that feedback without restriction and without any obligation to compensate, credit, or account to you, unless GeriPay expressly agrees otherwise in a separate signed writing. This allows GeriPay to improve, redesign, repair, retire, or expand the Service based on ordinary product feedback without creating future ownership or payment disputes over generalized ideas or product-direction input.

This subsection does not transfer ownership of underlying customer data merely because feedback or support communications happen to mention or include customer-linked records. It also does not create a duty of confidentiality for ordinary unsolicited feedback merely because the sender would prefer that result later. If a customer wants a separate confidentiality, work-product, invention-assignment, or custom-development arrangement for a particular exchange, that arrangement must be separately and expressly documented. Absent such a separate written arrangement, ordinary support messages, feature requests, product suggestions, and similar feedback-related communications may be used by GeriPay on a no-obligation basis.

23.5 Brand features and public references

Except as expressly permitted by GeriPay in writing, you may not use GeriPay's name, logos, trademarks, service marks, product names, screenshots, distinctive layouts, report styling, verification terminology, badge-like indicators, or other brand features in advertising, publicity, domain names, account names, social-media handles, sales materials, app listings, comparative claims, or other public-facing materials in a way that suggests sponsorship, certification, partnership, endorsement, or official affiliation. The fact that the Service generates reports, verification-linked artifacts, or outward-facing pages that may display GeriPay branding does not create a broader trademark or publicity license. If you share Service artifacts with third parties, any GeriPay branding embedded in those artifacts remains part of the Service presentation, not a transferable brand-usage permission for other contexts.

Likewise, nothing in these Terms grants GeriPay an automatic right to use the customer's name, logo, marks, screenshots, or other brand features in marketing, customer lists, case studies, public references, or promotional statements. Any such use by either party should be governed by a separate written permission or other clear written agreement. This balanced structure is intentional: it prevents users from turning ordinary product access into a publicity right against GeriPay, while also preventing GeriPay from claiming implied customer-reference rights merely because an organization uses the Service.

23.6 Third-party and open-source materials

The Service may include, depend on, or interact with third-party software, open-source components, data sets, fonts, libraries, content, or other materials that are subject to separate licenses, notices, or attribution requirements. To the extent a third-party or open-source license grants you rights that cannot be limited by these Terms, that license governs those specific materials to that specific extent. Nothing in this Section 23 is intended to override a mandatory open-source license obligation or prevent GeriPay from providing required notices, attributions, or source-offer information where applicable.

At the same time, the presence of third-party or open-source materials in the Service does not narrow the rest of these Terms or create a broader right to the Service as a whole. Third-party and open-source components may be updated, substituted, deprecated, removed, or governed by their own limitations at any time, and GeriPay does not warrant that any particular component, library, integration, or outside material will remain available, unchanged, or independently supportable forever. This subsection is meant to preserve ordinary coexistence with outside licenses without weakening the ownership, limited-license, anti-misappropriation, feedback, or brand-feature protections elsewhere in this chapter.

Section 24. Disclaimer of Warranties

24.1 As-is and as-available baseline

To the fullest extent permitted by law, the Service is provided on an "as is," "as available," and "with all faults" basis. This applies across the full product surface, including uploads, source-record handling, SmartScan and automated extraction, receipt review, Reports, Verified PDFs, Verification Codes, the Public Verification Page, other public or semi-public verification surfaces, reimbursement workflows, payout-method handling, Payment History displays, support surfaces, and preservation or export-related functions. GeriPay makes no promise that these features will behave perfectly, remain unchanged, or fit the Customer's preferred legal, financial, accounting, policy, or operational use case.

No statement in the Service, no polished interface, no workflow label, no chronology display, no support interaction, and no earlier product behavior should be read to create a special warranty or special relationship unless GeriPay expressly and specifically says so in a separate signed writing. GeriPay is not undertaking a fiduciary, banking, payroll, accounting, audit, legal, fraud-clearing, or compliance-guarantor role by making the Service available.

24.2 No warranty of accuracy, completeness, or correctness

GeriPay does not warrant the accuracy, completeness, correctness, consistency, interpretation, classification, sequencing, continued currency, or fitness for reliance of receipt images, extracted fields, corrected records, reimbursement states, payout-method records, Payment History entries, Reports, Verified PDFs, verification-linked artifacts, logs, timelines, metadata, or other Service outputs. A record may look polished, organized, internally consistent, and current while still being incomplete, stale, misinterpreted, materially misleading, or dependent on a flawed source.

This disclaimer applies whether the issue comes from source-image quality, user error, admin correction, provider behavior, SmartScan logic, chronology mismatch, delayed updates, bank callbacks, public verification caching, archival inconsistency, or later-discovered facts. No user or organization should assume that visible structure, stored history, or a professional-looking export makes the underlying record correct, complete, or ready for downstream legal or operational reliance.

24.3 No warranty of entitlement, approval, payment, compliance, or legal effect

GeriPay does not warrant that any person is entitled to reimbursement, that any request will be approved, that any approval was validly authorized, that any amount is owed, that any payout will be made, that any destination belongs to the intended recipient, or that any "paid," "approved," "complete," or similar label reflects final legal or financial effect outside the Service. GeriPay does not warrant that use of the Service creates enforceable rights against an employer, administrator, bank, provider, merchant, recipient, insurer, auditor, regulator, or any other third party.

GeriPay also does not warrant that records or workflows generated through the Service are compliant with tax, payroll, accounting, labor, audit, sanctions, anti-corruption, internal-policy, or evidentiary requirements, or that the customer's use of the Service satisfies any special-purpose legal or regulatory standard. The customer remains responsible for its own review, legal interpretation, professional advice, internal policy design, and downstream compliance decisions.

24.4 No warranty of uninterrupted operation, security, or provider continuity

GeriPay does not warrant uninterrupted availability, error-free operation, uninterrupted provider support, perfect security, perfect fraud prevention, perfect preservation, perfect restore capability, perfect chronology, or stable behavior by third-party providers, storage systems, routing layers, email vendors, AI vendors, payout-adjacent providers, banks, or other infrastructure dependencies. Outages, degraded performance, provider substitutions, policy changes, routing shifts, account restrictions, security incidents, restore gaps, and partial or delayed facts are foreseeable realities of a service of this kind.

No customer or user should infer an uptime warranty, security warranty, delivery warranty, provider-continuity warranty, region-stability warranty, or restoration warranty from the mere fact that GeriPay uses recognized infrastructure or layered providers. Security measures and provider choices are part of GeriPay's operational posture; they are not guarantees that attacks, corruption, delivery failures, or provider-caused interruptions will not occur.

24.5 No warranty regarding AI or automated outputs

GeriPay does not warrant SmartScan, OCR, AI-assisted extraction, provider-supported inference, categorization, normalization, confidence signals, or other automated outputs to be accurate, complete, stable, non-hallucinatory, non-inferential, or suitable for special reliance. Automated output may vary over time, across providers, across model versions, across prompt patterns, or across technical conditions, and the same-looking input may produce different results at different times. Structured output does not equal factual validation.

This disclaimer extends to automated receipt interpretation, field mapping, classification, merchant interpretation, tax and payment-detail extraction, summary generation, exception handling, or any future automated feature layered onto the Service. GeriPay does not warrant model stability, prompt stability, provider stability, explainability, or the detection of fraud, manipulation, or omission merely because automated tooling is involved.

24.6 No warranty of downstream acceptance or outsider reliance

GeriPay does not warrant that an employer, organization, administrator, auditor, regulator, counterparty, bank, provider, insurer, court, arbitrator, investigator, advisor, or any other outsider will accept, trust, or rely on a Service output, Report, Verified PDF, Verification Code, the Public Verification Page, another public or semi-public verification surface, Payment History display, or preserved record for any particular purpose. GeriPay also does not warrant that any outsider will interpret those materials narrowly, correctly, or consistently with GeriPay's intended product meanings.

If the customer or another user shares a Service artifact with an outsider, that sharing does not create a separate warranty by GeriPay that the outsider will treat it as sufficient, authentic, complete, or final. Public visibility, downloadability, verification-linked formatting, or polished presentation does not convert a GeriPay artifact into a certified statement, audit opinion, legal opinion, or guaranteed proof acceptable to the recipient.

24.7 Local-law savings and non-waivable carveouts

Nothing in this Section 24 is intended to disclaim a warranty, remedy, or protection that cannot lawfully be disclaimed or limited under applicable law. If a court or other decision-maker concludes that a particular disclaimer cannot be enforced as written, that conclusion should be applied as narrowly as possible and should not broaden GeriPay's obligations beyond what non-waivable law actually requires.

Any local-law savings language in this Section 24 should be read as a narrow backstop, not as a general weakening of the warranty-disclaimer architecture. Except to the limited extent non-waivable law requires otherwise, the disclaimers in these Terms remain intended to apply fully and broadly across the Service and across all theories that might otherwise be used to imply promises GeriPay did not make.

Section 25. Limitation of Liability

25.1 Liability cap structure

To the fullest extent permitted by law, the aggregate liability of GeriPay, its affiliates if any, its licensors and providers, and its employees, contractors, agents, representatives, advisors, and other personnel if any arising out of or relating to the Service, these Terms, or any related dispute shall not exceed the total amounts paid by the Customer to GeriPay in the 12 months before the event giving rise to the claim, or $100 if no such amounts were paid. That cap is intended to apply in the aggregate, not per claim, and across all theories of liability, including contract, tort, negligence, strict liability, statutory claims, equitable claims, misrepresentation claims, contribution claims, and any other theory to the fullest extent permitted by law.

The cap is intended to block the argument that a low-cost, no-cost, or operational workflow tool silently becomes an unlimited risk sink because it sits near receipts, reimbursements, payment-related workflows, reports, verification artifacts, audits, employment disputes, provider incidents, or public-facing reliance scenarios. If the commercial structure introduces tiers, order forms, or enterprise-specific overrides, those should be handled expressly in the published Terms or in another controlling written agreement rather than inferred from use of the Service.

25.2 Excluded categories of damages

To the fullest extent permitted by law, GeriPay shall not be liable for indirect, incidental, consequential, special, exemplary, punitive, enhanced, reliance-based, or similar damages, or for loss of profits, loss of revenue, loss of business opportunity, loss of goodwill, loss of reputation, business interruption, replacement-cost damages, cost of cover, loss of anticipated reimbursement or compensation, loss of anticipated savings, or similar downstream harm, even if GeriPay was advised that such harm was possible or foreseeable.

These excluded categories include damages said to arise from flawed SmartScan output, manipulated receipts, delayed or disputed reimbursements, wrong-recipient issues, payout delays, bank returns, provider outages, account compromise, public verification misuse, outsider misinterpretation of reports, missing archives, delayed restoration, employment or workplace disputes, insurance disputes, audit fallout, regulatory scrutiny, or internal governance failures. The presence of a polished product surface or a preserved chronology does not convert those downstream losses into recoverable categories against GeriPay.

25.3 Product-specific loss examples

Without limiting the rest of this Section 25, GeriPay shall not be liable for losses arising from false, incomplete, or manipulated source records; SmartScan failures or misreads; mistaken corrections; disputed reimbursement decisions; duplicate or omitted records; payout-method errors; wrong-destination or wrong-beneficiary issues; delayed, failed, returned, or reversed payment-adjacent events; provider callback failures; stale payment-history displays; report-generation errors; verification-code misuse; public-verification overreliance; suspension or termination decisions; account takeover; phishing; malware; ransomware; insider misuse; infrastructure outages; regional routing issues; object-storage problems; or incomplete archival recovery.

The same rule applies where harm is said to arise because a user, organization, outsider, or provider treated the Service as if it were a bank, a payroll system, an accounting certification engine, a fraud-clearance tool, a legal records authority, or an audit opinion platform. GeriPay's proximity to a disputed workflow does not make GeriPay liable for every consequence that follows from the customer's use, misuse, overreliance, or downstream sharing of Service outputs.

25.4 Third-party, provider, and outsider-behavior losses

GeriPay shall not be liable, to the fullest extent permitted by law, for losses caused in whole or in part by organizations, administrators, members, delegates, beneficiaries, merchants, banks, payout providers, cloud or AI vendors, storage vendors, email vendors, auditors, regulators, law-enforcement actors, counterparties, insurers, or other outsiders. This is true whether those parties act negligently, fraudulently, abusively, inconsistently, unlawfully, slowly, incompletely, or based on their own policies, technical constraints, or misunderstandings.

If a third party rejects a report, misreads a verification page, delays a payout, routes funds incorrectly, mishandles a callback, imposes a hold, makes an adverse employment decision, starts an investigation, or otherwise creates downstream harm, that does not by itself shift liability to GeriPay merely because the Service recorded, displayed, preserved, or helped organize part of the underlying workflow. Third-party conduct and provider conduct remain major intervening risk factors that these Terms are intended to keep on the customer side except to the limited extent non-waivable law requires otherwise.

25.5 Data, preservation, and restoration-loss limits

GeriPay shall not be liable, to the fullest extent permitted by law, for loss, corruption, inaccessibility, delay, incompleteness, mismatch, or incomplete restoration of data, attachments, source images, extracted fields, reimbursement records, payout-method records, Payment History records, Reports, Verified PDFs, verification-linked assets, logs, legal-acceptance evidence, backups, archives, or other technical and evidentiary materials. This applies whether the issue arises from user action, provider action, storage behavior, deletion, overwrite, malware, outage, routing change, migration, restoration gap, preservation choice, or legal-hold handling.

Even where GeriPay preserves substantial historical material, GeriPay does not undertake to preserve every record in an ideal format, every chronology in exact order, every preview path, or every download surface in perpetuity. Liability is limited even if preserved evidence is incomplete, even if some archives remain inaccessible, and even if restoration returns some but not all layers of the historical record.

25.6 Essential purpose, cumulative remedies, and local-law savings

If a court or other decision-maker concludes that a particular remedy fails of its essential purpose, or that a particular exclusion or limit cannot be enforced as written, the parties nevertheless intend the remaining limitations, exclusions, caps, and liability-allocation rules in these Terms to survive and be enforced to the maximum extent permitted by law. No narrow failure of one part of the remedial architecture should be read to reopen broad consequential-damages exposure or unlimited category-by-category liability.

Any local-law savings required in this Section 25 should be read narrowly and should not be used to expand GeriPay's liability beyond what mandatory law actually requires. To the fullest extent permitted, the cap, the excluded-damages provisions, the product-specific loss examples, and the provider- and outsider-causation limits should continue to apply independently and cumulatively.

Section 26. Indemnity

26.1 Indemnifying parties and scope of responsibility

You shall defend, indemnify, and hold harmless GeriPay from and against claims, demands, investigations, actions, proceedings, liabilities, damages, judgments, settlements, penalties, fines, costs, and expenses, including reasonable attorneys' fees and professional fees, arising out of or relating to your use of the Service, your records, your submissions, your instructions, your legal violations, your internal governance failures, or your breach of these Terms. If you access or use the Service on behalf of an organization, that organization is responsible for the acts, omissions, instructions, authority failures, policy failures, and misuse of its administrators, members, employees, contractors, and other representatives to the fullest extent permitted by law.

This indemnity is intended to reach both direct conduct and conduct carried out through apparently authorized roles, stale authority, delegated access, shared credentials, collusive approval chains, or other customer-side structures. GeriPay is not required to sort every customer-side fault line with surgical precision before asserting indemnity where the claim exposure is materially tied to the customer's users, data, workflows, or decisions.

26.2 Indemnified parties

The indemnified parties include GeriPay, its affiliates if any, licensors, providers, successors, assigns, and each of their respective employees, contractors, agents, representatives, advisors, and other personnel if any to the extent the relevant claim or cost relates to the Service or these Terms. GeriPay may assert indemnity for itself and, where appropriate, for other indemnified parties materially exposed by the customer's conduct, submissions, workflows, or disputes.

Nothing in this subsection makes every provider a general third-party beneficiary of every part of these Terms, but it does preserve GeriPay's ability to protect those parties where the customer's conduct creates provider-linked or affiliate-linked claim exposure that GeriPay reasonably must address. The indemnified-party concept should be read broadly enough to support actual claim defense, not narrowly enough to defeat it through formal labels.

26.3 Claim triggers tied to product-specific misuse

Indemnity applies, without limitation, to claims or losses arising from false, manipulated, forged, incomplete, unauthorized, or misleading uploads; SmartScan-related misuse; incorrect or deceptive corrections; reimbursement fraud; false approvals; duplicate claims; payout-method misuse; wrong-recipient disputes; beneficiary-ownership disputes; public-verification misuse; report-sharing misuse; outsider reliance theories caused by your sharing or characterization of Service artifacts; privacy or confidentiality violations in materials you submit or distribute; intellectual-property violations; lack of authority to bind an organization or act within a workspace; sanctions, bribery, corruption, or books-and-records-style misconduct; and obstruction, deletion, or distortion of evidence.

Indemnity also applies where the Service is used to create a false appearance of legitimacy, a false paper trail, a false compensation narrative, a false audit posture, or a false proof-of-payment story, even if GeriPay did not detect the problem before a third party relied on or reacted to the resulting records. If customer-side conduct turns GeriPay's workflows, reports, or preserved records into part of a dispute, claim, investigation, or enforcement matter, the customer bears that risk to the fullest extent permitted by law.

26.4 Third-party reliance, employment, policy, and internal-dispute claims

Indemnity extends to claims by employees, members, contractors, recipients, merchants, auditors, regulators, counterparties, insurers, or other third parties arising from the customer's reimbursement policies, approval structures, payout decisions, beneficiary validation failures, payment-history interpretation, report sharing, public-verification sharing, employment decisions, compensation disputes, internal investigations, recordkeeping choices, or internal-control failures. GeriPay is not required to absorb employment, workplace, HR, compensation, or policy-enforcement disputes merely because the Service was used somewhere in the factual background.

If a customer presents a GeriPay artifact as proof of entitlement, proof of payment, proof of authenticity, proof of compliance, or proof of proper internal handling, and that characterization later becomes part of a dispute or claim, the resulting exposure remains on the customer side. The same is true where outsiders rely on, reject, or challenge Service artifacts because of how the customer shared, labeled, excerpted, or contextualized them.

26.5 Defense control, cooperation, and information-sharing

GeriPay may assume, direct, or coordinate the defense of any indemnified matter, may choose counsel, may participate with counsel of its choice, and may require the customer to cooperate promptly and in good faith. That cooperation includes preserving evidence, producing documents, identifying knowledgeable personnel, explaining chronology, validating authority, describing internal policies, supplying communications, and taking reasonable steps to avoid prejudicing the defense. GeriPay may also coordinate with providers, insurers, experts, advisors, and authorities as reasonably necessary.

If the customer delays, withholds, distorts, or destroys relevant information, GeriPay may take defensive steps based on the record then available, and the customer remains responsible for the resulting consequences to the fullest extent permitted by law. Defense and cooperation duties under this subsection are intended to work together with the monitoring, preservation, and legal-process rights elsewhere in these Terms, not to replace them.

26.6 Settlement control and admissions

No indemnified matter may be settled, compromised, admitted, conceded, or otherwise resolved in a way that imposes fault, obligations, restrictions, confidentiality burdens, injunctive terms, operational changes, or other adverse effects on GeriPay without GeriPay's prior written consent. The customer may not make factual admissions, legal admissions, or public statements that purport to bind GeriPay or characterize GeriPay's role in a disputed matter without GeriPay's prior written approval.

GeriPay may withhold consent where a proposed resolution would impair its defenses, require changes to the Service, expose its providers, distort preserved chronology, or create precedent harmful to other matters. If GeriPay elects to control or coordinate settlement strategy, the customer must cooperate and remains responsible for indemnified costs and obligations to the fullest extent permitted by law.

26.7 Survival and interaction with liability limits

The indemnity obligations in this Section 26 survive restriction, suspension, termination, account closure, workspace removal, deletion requests, later policy updates, and the end of any other active use relationship. They remain available for claims and expenses arising from past conduct, past records, past sharing, past authority failures, or later-discovered consequences of earlier use of the Service.

Unless non-waivable law or an express signed written agreement says otherwise, the liability cap and exclusions that protect GeriPay are not intended to limit the Customer's defense, payment, cooperation, or indemnification obligations under this Section 26. This subsection is intended to operate as a separate claim-shifting backstop, not as a narrow sub-part of Customer-side damages arguments.

Section 27. Disputes, Arbitration, Venue, and Governing Law

27.1 Informal dispute notice and pre-filing process

Before filing arbitration or court proceedings arising out of or relating to the Service or these Terms, the complaining party must first send a written notice of dispute to the other party using GeriPay's designated legal-notice channel at legal@geripay.com. That notice must identify the claimant, the relevant account or organization, the factual basis of the dispute, the legal basis of the dispute, the specific relief requested, and the supporting information reasonably necessary to evaluate the claim. A vague threat, support ticket, social-media complaint, or informal escalation does not satisfy this requirement.

The parties must then engage in a good-faith pre-filing resolution process for 30 days. A proceeding filed before a compliant notice is delivered and the required period runs may be treated as premature to the fullest extent permitted by law. The purpose of this subsection is to create a real gate for serious claims, not a casual courtesy exchange, and no party may use noncompliant notice gamesmanship to manufacture procedural leverage.

27.2 Arbitration agreement framework

Except for the limited carveouts expressly stated in these Terms or required by non-waivable law, any dispute arising out of or relating to the Service, these Terms, onboarding, invite acceptance, electronic assent, legal-acceptance evidence, receipts, SmartScan, Reports, public verification, reimbursements, payout methods, Payment History, privacy, security, suspension, termination, or related interactions shall be resolved by binding arbitration on an individual basis. The arbitration administrator designated in these Terms is JAMS under its applicable rules then in effect, subject to any modifications validly stated in the published version of these Terms. The Federal Arbitration Act shall govern the interpretation and enforcement of the arbitration agreement to the fullest extent permitted by law.

To the fullest extent permitted by law, the arbitrator, and not a court, shall decide issues relating to the scope, enforceability, formation, interpretation, or arbitrability of this arbitration agreement, except to the limited extent applicable law requires a court to decide a particular issue. If the selected administrator is unavailable or declines to administer the matter, the parties intend for a comparable individual arbitration process to be used rather than for arbitration to fail automatically. This subsection is meant to channel disputes away from broad court litigation and toward an individualized, controlled, and enforceable process.

27.3 Excluded claims and court-access carveouts

Nothing in this Section 27 prevents either party from seeking relief in court where non-waivable law forbids arbitration of a particular claim, where a court proceeding is necessary to compel arbitration, confirm or challenge an arbitration award, or obtain limited provisional or equitable relief to protect confidentiality, security, intellectual property, public-verification integrity, evidence preservation, or other interests that cannot reasonably wait for the full arbitration process. Any such court proceeding must remain as narrow as possible and should not be used to bypass the arbitration core of this Section 27.

Unless the published version of these Terms expressly includes a narrow small-claims carveout or a narrower defined court-access path, no such carveout exists. If such a carveout is added before publication, it must be read narrowly and must not be used to coordinate, aggregate, or repackage broader disputes that otherwise belong in arbitration. The intended posture of these Terms is that court access is exceptional, supportive, or legally mandatory, not an ordinary alternative to the individualized arbitration path.

27.4 Individual-only proceedings, class waiver, and representative-action limits

To the fullest extent permitted by law, all disputes must be brought solely in an individual capacity and not as a plaintiff, claimant, class member, representative, relator, private attorney general, or participant in any class, collective, representative, coordinated, or consolidated proceeding. No arbitration shall proceed on a class basis, no arbitrator shall preside over a consolidated or representative matter, and no party may combine or aggregate claims except to the limited extent these Terms or mandatory law expressly and validly permit.

This waiver is intended to prevent ordinary class-action and representative-action pressure, but also to prevent repackaged versions of the same concept through coordination tactics, proxy claimants, or label changes. If a court or arbitrator determines that a waiver in this subsection cannot be enforced for a particular claim or procedural posture, that determination should be applied as narrowly as possible, and the rest of the dispute-control architecture should remain in force to the fullest extent permitted by law.

27.5 Batch or mass arbitration handling

If many similar claims are filed by or with the assistance of the same law firm, related law firms, coordinated claim groups, or other persons acting in concert, the parties intend that the administrator, arbitrator, or court, as applicable and to the fullest extent permitted by law and applicable rules, may batch, stage, sequence, bellwether, or otherwise administer the claims in a way that preserves their individual character while avoiding abusive or inefficient mass-filing pressure. No claimant may use coordinated filing volume alone to argue that GeriPay waived individualized procedure or must immediately litigate or settle all related matters at once.

This subsection should be interpreted to preserve the maximum lawful room for staged administration, batching, fee-order control, and other anti-gamesmanship tools without abandoning the individualized dispute model that the rest of this Section 27 is designed to create. If an administrator's applicable mass-arbitration or case-management rules later require adjustment, the parties intend to preserve individualized dispute handling to the fullest extent permitted by law rather than allow coordinated filing pressure to collapse the broader dispute-control structure.

27.6 Governing law and venue fallback

These Terms and any dispute arising out of or relating to them shall be governed by the Federal Arbitration Act where applicable and otherwise by the laws of the State of Illinois, without regard to conflict-of-law principles to the extent such principles would cause another jurisdiction's law to apply. If a dispute proceeds in court because a court proceeding is expressly permitted or because arbitration is unavailable for a particular claim, the parties consent to exclusive jurisdiction and venue in the state or federal courts located in Cook County, Illinois, subject to any mandatory law that requires a narrower or different result.

The governing-law and venue structure in this subsection is a deliberate part of the risk-allocation and dispute-control package. It is intended to discourage forum shopping, avoid a patchwork of inconsistent state rules where law allows, and keep related proceedings in a predictable forum rather than allowing geographically scattered dispute tactics driven by workflow artifacts, the Public Verification Page, other public or semi-public verification surfaces, or multi-user organizational use.

27.7 Jury waiver, judge-only proceedings, and procedural waivers

To the fullest extent permitted by law, and for any claim that proceeds in court rather than arbitration, each party knowingly and voluntarily waives any right to a jury trial. Any such permitted court proceeding shall be resolved by a judge alone, and the parties intend this waiver to apply to contract claims, tort claims, statutory claims, equitable claims, and other theories to the fullest extent the law permits.

This jury-waiver posture is intended to work together with the arbitration, class-waiver, venue, and informal-resolution provisions rather than as an isolated procedural clause. If a particular aspect of this subsection is later found unenforceable for a specific claim, the remaining dispute-control provisions should still be interpreted to preserve the most individualized, non-jury, non-aggregated path allowed by law.

27.8 Time limits, claim-filing limits, and equitable relief support

To the fullest extent permitted by law, any claim arising out of or relating to the Service or these Terms must be commenced within the shortest contractual limitations period allowed by applicable law, and in any event no later than one year after the claim arose or should reasonably have been discovered, unless a different period is required by non-waivable law. Claims not brought within that period are permanently barred. This timing rule is intended to limit stale disputes, fading memories, missing evidence, and after-the-fact reinterpretation of historical workflow records.

Nothing in this subsection prevents a party from seeking temporary, emergency, or equitable relief where genuinely necessary to protect confidentiality, security, public-verification integrity, intellectual property, evidence, or other interests that cannot reasonably wait for full merits resolution. But any such relief must remain supportive of, and not destructive of, the rest of the dispute-control architecture in this Section 27.

27.9 Confidentiality, preserved evidence, and dispute materials

To the fullest extent permitted by law and applicable forum rules, arbitration proceedings, written submissions, evidence, awards, settlement discussions, and related dispute materials may be treated as confidential between the parties except to the extent disclosure is reasonably necessary to pursue, defend, enforce, insure, advise on, preserve, or resolve the dispute, comply with law or legal process, respond to regulators or auditors, coordinate with providers or experts, or communicate with persons who reasonably need the information for the matter. Confidential treatment, where available, does not bar lawful preservation, compelled production, or otherwise necessary disclosure to insurers, providers, experts, advisors, auditors, courts, arbitrators, or authorities.

The parties may use preserved operational records, legal-acceptance evidence, workflow chronology, logs, provider communications, Reports, verification-linked artifacts, and related materials in dispute proceedings to the fullest extent permitted by law and applicable rules. The existence of confidentiality protections does not require GeriPay to ignore preserved evidence, does not require GeriPay to present only customer-favorable materials, and does not prevent GeriPay from using historically preserved or provider-backed records to support enforcement, defense, or procedural requests in arbitration or court-support proceedings.

27.10 Administrative detail updates and fallback construction

This Section 27 should be interpreted to preserve individualized dispute resolution, anti-aggregation control, and Illinois- and Cook-County-oriented fallback structure even if administrative details later change, become unavailable, or require legally necessary adjustment, including the legal-notice address, the arbitration administrator reference, the applicable rule reference, or another comparable implementation detail permitted by law. If one administrative detail changes, becomes unavailable, or later requires a legally necessary adjustment, the rest of the dispute-control architecture remains in effect and should be construed to carry out the parties' clear intent to use individualized, non-class, non-representative proceedings to the maximum extent permitted by law.

If a court or arbitrator concludes that one procedural or administrative aspect of this Section 27 cannot be enforced exactly as written, that determination should not be used to collapse the rest of the arbitration, class-waiver, venue, jury-waiver, timing-limit, or anti-gamesmanship structure. The parties intend the remaining provisions to survive, be narrowed only as much as necessary, and continue operating as an integrated dispute-resolution system.

Section 28. Miscellaneous Legal Mechanics

28.1 Assignment and transfer

GeriPay may assign, transfer, delegate, subcontract, or otherwise move these Terms or any of its rights and obligations under them, in whole or in part, to an affiliate, successor, acquirer, reorganized entity, financing party, or other party involved in a merger, acquisition, restructuring, asset transfer, or comparable transaction. GeriPay may also use providers and contractors to perform portions of the Service without obtaining separate customer consent for each internal or provider-supported operational arrangement.

You may not assign, transfer, delegate, resell, sublicense, or otherwise move your rights or obligations under these Terms, whether by operation of law, change of control, internal reorganization, nominee arrangement, or otherwise, without GeriPay's prior written consent. Any attempted customer-side transfer in violation of this subsection is void to the fullest extent permitted by law and does not bind GeriPay.

28.2 Force majeure and events beyond reasonable control

GeriPay shall not be liable for delay, interruption, degradation, data-access limitations, changed behavior, or nonperformance caused by events beyond GeriPay's reasonable control, including provider outages, cloud failures, storage failures, routing failures, internet or telecom disruptions, DNS or certificate issues, legal or regulatory changes, sanctions restrictions, labor disruptions, civil unrest, natural disasters, public-health events, war, terrorism, cyberattacks, ransomware, malware events, widespread fraud campaigns, power failures, banking or payout-rail failures, or other infrastructure or governmental events that materially affect the Service or its dependencies.

During such events, GeriPay may suspend or narrow performance, redesign workflows, change provider paths, delay response, limit support, preserve evidence, or otherwise act in a manner it reasonably believes appropriate under the circumstances. The existence of a force-majeure event does not create a duty to continue every feature in full, to disclose every underlying provider fact immediately, or to achieve exact restoration after the event subsides.

28.3 Notices and communication channels

GeriPay may provide notices under these Terms through email, in-product presentation, account messages, posted updates, archived legal-record flows, postal mail where chosen, or other channels reasonably associated with the relevant account or organization. Notices are effective when sent, posted, or made available through the applicable channel to the fullest extent permitted by law, even if the customer later claims not to have checked the channel, provided contact details, or maintained access in a timely way.

You are responsible for keeping contact information accurate and current, monitoring the channels associated with your account and organization, and routing legal or operational notices internally to the appropriate decision-makers. GeriPay is not responsible for a customer's internal mail-routing failures, stale inboxes, abandoned admin accounts, or unmonitored notice channels. This subsection should be read together with the electronic-records consent framework in Section 7.

28.4 Waiver, severability, and interpretation after partial invalidity

No failure or delay by GeriPay in exercising a right, remedy, or provision under these Terms waives that right, remedy, or provision. A single or partial exercise does not prevent later or further exercise, and informal lenience, support communication, delay, or failure to object in one situation does not create a binding modification or waiver for any later situation. Waivers must be express and in writing to be effective.

If any provision of these Terms is held invalid, unenforceable, or unlawful in whole or in part, that provision shall be enforced to the maximum extent permitted by law and the remainder of these Terms shall remain in full force and effect. This subsection is intended to preserve the liability, indemnity, arbitration, class-waiver, jury-waiver, preservation, and anti-reliance architecture even if a specific clause must later be narrowed, severed, or reformed.

28.5 Entire agreement and no extra-contractual reliance

These Terms, together with the Privacy Policy and any other document expressly incorporated by reference or expressly signed by GeriPay as part of the parties' governing agreement, constitute the entire agreement between the parties regarding the subject matter addressed here. They supersede prior or contemporaneous proposals, drafts, discussions, emails, chats, support shorthand, marketing materials, screenshots, demonstrations, labels, and other informal or partial statements concerning the same subject matter, except to the limited extent a separately signed writing expressly controls.

No party is relying on extra-contractual statements, implied product promises, unlabeled screenshots, old draft language, stale UI wording, informal support statements, or a third party's description of GeriPay in deciding whether the Service creates rights, duties, warranties, certification value, payment obligations, or legal effect. This subsection is intended to block the conversion of informal product language into contract promises that do not appear in the final governing documents.

28.6 Independent parties and no third-party beneficiaries

The relationship between the parties is that of independent contracting parties only. Nothing in these Terms creates a partnership, joint venture, agency, employment, fiduciary, trustee, paymaster, payroll, custody, or similar special relationship between GeriPay and any customer, administrator, member, recipient, merchant, bank, provider, or outsider. No party may represent otherwise.

Except where these Terms expressly provide protection to certain indemnified or related parties, no person or entity that is not a party to these Terms is intended to be a third-party beneficiary with a right to enforce them. In particular, employees, members, merchants, banks, providers, auditors, regulators, recipients, or counterparties do not gain direct contract rights against GeriPay merely because the Service touches records or workflows relevant to them.

28.7 Export controls, trade restrictions, and law-compliance catchall

You may not access, use, export, re-export, transfer, or otherwise use the Service in violation of applicable export-control laws, trade restrictions, sanctions restrictions, or other legal requirements governing access to software, data, providers, or technical functionality. GeriPay may restrict, deny, or terminate access where export-control, sanctions, or trade-law concerns exist or where provider rules or law make continued access inappropriate.

This subsection is a broad compliance catchall and does not limit more specific restrictions elsewhere in these Terms. The fact that GeriPay does not identify or block every restricted scenario does not mean any scenario is permitted, lawful, or approved. Compliance duties remain on the customer side unless a non-waivable law imposes a narrower allocation.

28.8 Survival

The provisions of these Terms that by their nature should survive restriction, suspension, termination, account closure, role removal, or the end of active use shall survive, including without limitation provisions concerning legal-acceptance evidence, Customer responsibilities, product-output limitations, reimbursement and payout risk allocation, prohibited conduct, provider dependence, security and incident posture, monitoring and investigations, preservation and legal process, intellectual property, warranty disclaimers, limitations of liability, indemnity, dispute resolution, governing law, venue, jury waiver, notices, anti-circumvention, export and trade restrictions, and this Section 28.

The survival of a provision does not depend on whether the customer still has dashboard access, whether a workspace remains active, or whether a public artifact remains visible. If a provision is functionally necessary to interpret past conduct, preserve evidence, allocate risk, defend a claim, or prevent circumvention after access ends, it should be treated as surviving to the fullest extent permitted by law whether or not it is expressly listed above.

28.9 Headings, formatting, and document-control mechanics

Section titles, headings, numbering, formatting choices, examples, and internal document-control labels are included for convenience and organizational clarity only. They help structure the document, but they do not by themselves narrow or expand substantive rights or duties. Version labels, archived copies, and formatting differences may be relevant to historical traceability, but they do not change the legal meaning of the text simply because later copies are styled, paginated, or labeled differently.

GeriPay may maintain archived, reformatted, normalized, or otherwise administratively different copies of these Terms for preservation, comparison, or version-control purposes. Minor formatting or presentation differences across preserved copies, downloads, internal archives, or evidentiary packages do not by themselves create a conflict or invalidate the underlying text where the substantive content is materially the same.

28.10 Further assurances and residual interpretive mechanics

Each party shall cooperate with reasonable administrative or documentary steps needed to carry out the lawful intent of these Terms where a minor clerical, cross-reference, notice-detail, or comparable housekeeping issue is later identified, provided that such cooperation does not impose a materially new substantive obligation not already reflected in the governing text. Administrative completion or correction of such details does not by itself waive, narrow, or undo the allocation, disclaimer, liability, dispute, or enforcement architecture stated elsewhere in these Terms.

If a question later arises about where a closing housekeeping point belongs within the document, these Terms should be interpreted in a way that preserves coherent operation rather than in a way that treats the agreement as defeated by the absence, relocation, or later cleanup of a residual mechanics clause. This subsection is intended to support orderly interpretation, completion, and administration of the agreement without reopening the core allocation of risk and responsibility stated elsewhere in these Terms.