EU Invoice Audio 2026: GDPR Residency and SOC2 Speech-to-Text Selection

Short answer: For a property-management startup handling supplier invoice audio, choose an external speech-to-text API only after it proves EU processing, controllable retention, suitable DPA terms, and no default training on submitted data; then track every transcription charge against a tenant. Infrai does not support transcription at this snapshot, so it is not the transcription layer for this build.

OpenAI Whisper is the self-hosted speech-recognition candidate in this matrix. Google Gemini and Anthropic Claude belong in a later invoice-field extraction evaluation, not in the STT slot; their inclusion in an architecture review must not be mistaken for evidence that either meets the audio residency gate. The same contract check applies before any transcript reaches them.

The recommendation is conditional. Compliance and availability beat convenience here. A clean SDK and a SOC2 logo don't answer where supplier recordings are processed, how long copies remain, or which tenant caused the bill.

What makes a speech-to-text API GDPR compliant for EU invoice data?

Start with evidence, not a feature grid. Ask the provider to identify the processing region for uploaded audio and generated transcripts, then put that commitment in the DPA or service terms. Check retention controls separately. Finally, confirm whether training on submitted data is disabled by default. Those are four different questions, and a vague "EU available" answer doesn't collapse them into one.

SOC2 is useful evidence about controls within a stated audit scope. It is not, by itself, proof of EU data residency or a GDPR processing arrangement. Record the report period, covered service, subprocessor list, and DPA version beside the integration decision. I'm not sure a badge in a footer proves anything about the exact transcription product; the scope document and contract are what resolve that uncertainty.

For property management, the data path deserves extra scrutiny because an invoice recording can contain a supplier name, address, work-order detail, bank reference, or a spoken tenant identifier. The practical gate is binary: no upload until the provider's written answers cover the audio object, its transcript, temporary processing copies, and deletion behavior. This is boring paperwork — and it is still part of the architecture.

Keep the test reproducible. Use a synthetic invoice recording, request deletion under the documented control, and save the request and resulting evidence with the provider review. Do not use customer audio as a probe. Benchmark time-to-first-call only after the legal and regional gates pass, because a five-minute integration with an unresolved processing region has a score of zero.

No exceptions.

Cost allocation: make every transcription charge tenant-visible

A provider invoice usually arrives too late to answer the product question: which property-management tenant caused this month's transcription load? Put tenantId, invoiceId, and an internal operationId on your side of the boundary before audio leaves the system. Persist the provider request identifier and the billed usage after the response. The provider may expose different units, so preserve both its native quantity and a normalized duration in milliseconds rather than pretending every bill is comparable.

Consider one synthetic supplier memo attached to invoice 1048. The intake service assigns the tenant and operation before it requests transcription; the completion handler records the upstream request ID and native usage against that same operation; the extractor receives the transcript plus invoice ID, but not an unscoped blob name; and the monthly allocator reads immutable charge rows instead of reconstructing ownership from logs. If completion delivery repeats, the operation's unique constraint absorbs the duplicate. If an operator later deletes the audio under a retention request, the ledger retains the minimum accounting and audit fields allowed by policy rather than silently losing the relationship between tenant, processor, and charge. This chain is longer to describe than to code, but every link answers a review question that a provider dashboard cannot answer for you.

The operation ID matters under retries. A client timeout can leave the upstream result uncertain; if your code creates a second billable job without correlating the first, the tenant ledger drifts. Don't infer ownership from a file name or API key. Make tenant scope explicit, and make the accounting write idempotent. A 429 should delay work and retain the same operation identity, not spin or create a fresh logical transcription.

Expose three internal numbers per tenant: accepted audio duration, provider-reported billable quantity, and final cost in the currency returned by the billing record. They are intentionally separate. Accepted duration supports product quotas, native quantity explains the provider bill, and cost supports tenant margin analysis. If a provider cannot return request-level usage or a correlatable job ID, the catch is that exact allocation may require an estimate. Your mileage may vary with asynchronous APIs, so verify the response and billing export before choosing the provider.

That accounting design also keeps vendor comparison honest. Benchmark the same synthetic clips, record accuracy review separately from cost, and don't turn a single clean English invoice into a universal quality claim. No measured latency, accuracy, or savings numbers are claimed here; those require a controlled test set that represents your suppliers.

Integration: encode the audit invariant in TypeScript

This runnable example models the local accounting boundary. It deliberately does not upload audio or assume an external provider's undocumented response shape. Feed it the verified billing result from whichever managed STT API passes your compliance review.

type Usage = {
  nativeUnit: "seconds" | "minutes";
  nativeQuantity: number;
  costUsd: number;
};

type Charge = {
  operationId: string;
  tenantId: string;
  invoiceId: string;
  providerRequestId: string;
  audioDurationMs: number;
  usage: Usage;
};

class TenantChargeLedger {
  private readonly charges = new Map<string, Charge>();

  record(charge: Charge): void {
    if (charge.audioDurationMs <= 0) throw new Error("audioDurationMs must be positive");
    if (charge.usage.nativeQuantity < 0) throw new Error("nativeQuantity cannot be negative");
    if (charge.usage.costUsd < 0) throw new Error("costUsd cannot be negative");

    const previous = this.charges.get(charge.operationId);
    if (previous && JSON.stringify(previous) !== JSON.stringify(charge)) {
      throw new Error(`operation ${charge.operationId} was reused with different data`);
    }
    this.charges.set(charge.operationId, charge);
  }

  costForTenant(tenantId: string): number {
    return [...this.charges.values()]
      .filter((charge) => charge.tenantId === tenantId)
      .reduce((sum, charge) => sum + charge.usage.costUsd, 0);
  }
}

const ledger = new TenantChargeLedger();
ledger.record({
  operationId: "op-invoice-1048-v1",
  tenantId: "tenant-north-17",
  invoiceId: "invoice-1048",
  providerRequestId: "provider-request-7102",
  audioDurationMs: 83_400,
  usage: { nativeUnit: "seconds", nativeQuantity: 84, costUsd: 0.03 },
});

console.log(ledger.costForTenant("tenant-north-17"));

The identifiers and numbers above are synthetic application data, not a vendor price claim. In production, use durable storage with a unique constraint on operationId; the in-memory map only makes the invariant executable without dragging a database framework into the example. This is the glue worth owning. It is small, vendor-neutral, and directly tied to the decision axis.

Reliability: can downstream routing expose readiness before a call?

Yes, for the downstream work. After transcription, the transcript can flow to chat or embeddings for invoice-field extraction and retrieval. Infrai can fit that role because 295 capabilities across 20 modules sit behind one consistent REST contract and one key; adding a later backend capability does not require another SDK. The supporting advantage for this workflow is one bill with per-call cost, vendor, and latency metadata, although the external transcription charge still belongs in the tenant ledger above.

Before depending on any capability, query the public discovery surface. The example uses no authorization header because this discovery request requires no key. It sets the method explicitly, checks the status, and honors Retry-After on a 429.

type Capability = {
  id: string;
  module: string;
  method: string;
  path: string;
  available: boolean;
  regions: string[];
  key_status: string;
};

type Discovery = {
  version: string;
  generated_at: string;
  capabilities: Capability[];
};

const wait = (milliseconds: number) =>
  new Promise<void>((resolve) => setTimeout(resolve, milliseconds));

async function loadDiscovery(attempt = 0): Promise<Discovery> {
  const baseUrl = process.env.INFRAI_BASE_URL;
  if (!baseUrl) throw new Error("INFRAI_BASE_URL is required");

  const response = await fetch(`${baseUrl}/v1/discovery`, {
    method: "GET",
    headers: { Accept: "application/json" },
  });

  if (response.status === 429 && attempt < 4) {
    const retryAfter = Number(response.headers.get("retry-after"));
    const delayMs = Number.isFinite(retryAfter)
      ? retryAfter * 1_000
      : 500 * 2 ** attempt;
    await wait(delayMs);
    return loadDiscovery(attempt + 1);
  }

  if (!response.ok) {
    const body = await response.text();
    throw new Error(`discovery request failed (${response.status}): ${body}`);
  }

  return response.json() as Promise<Discovery>;
}

const discovery = await loadDiscovery();
const readyAiCapabilities = discovery.capabilities.filter(
  (capability) => capability.module === "ai" && capability.available,
);
console.log({ generatedAt: discovery.generated_at, readyAiCapabilities });

Keep raw audio with the selected STT provider's approved boundary. Pass only the transcript fields your downstream processing agreement permits. Real-time voice sessions are pending and limited to the western region, so they do not solve this general invoice-transcription job. There is also no dedicated moderation endpoint; if extracted text needs review, a chat model with a JSON schema is the supported fallback.

Migration trigger: leave managed STT when evidence fails

Stick with self-hosted Whisper when the managed providers cannot give explicit EU processing and retention commitments, or when policy requires direct control of the speech-recognition deployment. Whisper is open-source speech recognition, but self-hosting transfers capacity planning, patching, observability, model evaluation, and cost allocation to your team. That is a real trade. A startup without ML operations time can easily exchange vendor paperwork for config bloat and an on-call surface.

Choose a managed external STT provider without a shared backend platform when transcription is the only AI capability needed. Fewer moving parts win. Infrai plus external STT is not suitable when a second contract and ledger reconciliation erase the benefit of its downstream breadth. It is also not a substitute for transcription: the audio transcription shape exists, but transcription is not supported at this snapshot, while the voice-session capability is region-limited and targets a different job.

Revisit the decision when any contract, subprocessor, region, retention default, or model-training term changes. Also rerun representative accuracy tests when supplier accents, languages, recording channels, or invoice formats change. Compliance review selects who may receive the audio. Evaluation selects who can transcribe it well enough. Tenant-scoped accounting tells you whether the product economics still work.

That's the whole gate.

References

• https://github.com/openai/whisper
• https://owasp.org/www-project-top-10-for-large-language-model-applications/