import type { Metadata } from "next";
import { notFound } from "next/navigation";
import Image from "next/image";
import { Header } from "@/components/landing/Header";
import { Footer } from "@/components/landing/Footer";
import { RelatedReading, SeoLink } from "@/components/landing/RelatedReading";
import { siteUrl } from "@/lib/seo/site";
import { publicUrl, seoLanguageAlternates } from "@/lib/seo/slugs";

type Locale = "de" | "en";
function isLocale(value: string): value is Locale {
  return value === "de" || value === "en";
}

const ROUTE = "blog/how-receipt-ocr-works" as const;
const PUBLISHED = "2026-08-19";

const copy = {
  de: {
    title: "So funktioniert Beleg-OCR wirklich | ScanReceipts",
    description:
      "Wie KI Kassenbons wirklich ausliest, warum Thermopapier für OCR eine Herausforderung ist und warum ein Rechen-Check nach der KI unverzichtbar ist.",
    keywords: [
      "ocr kassenbon",
      "kassenbon ocr",
      "beleg ocr",
      "rechnung ocr",
      "ocr rechnungen",
    ],
  },
  en: {
    title: "How Receipt OCR Actually Works | ScanReceipts",
    description:
      "A plain-language technical explainer on receipt OCR and AI extraction — why thermal receipts are hard to read and why arithmetic verification matters.",
    keywords: [
      "receipt ocr",
      "ocr receipt scanner",
      "ai receipt scanner",
      "receipt data extraction",
    ],
  },
} as const;

export async function generateMetadata({
  params,
}: {
  params: Promise<{ locale: string }>;
}): Promise<Metadata> {
  const { locale } = await params;
  const lang: Locale = isLocale(locale) ? locale : "en";
  const canonical = publicUrl(lang, ROUTE);
  const c = copy[lang];
  return {
    title: c.title,
    description: c.description,
    keywords: [...c.keywords],
    alternates: {
      canonical,
      languages: seoLanguageAlternates(ROUTE),
    },
    openGraph: {
      type: "article",
      url: canonical,
      siteName: "ScanReceipts",
      title: c.title,
      description: c.description,
      locale: lang === "de" ? "de_DE" : "en_US",
      alternateLocale: lang === "de" ? "en_US" : "de_DE",
      images: [{ url: `${siteUrl}/screenshot-inspector-review.png`, width: 1295, height: 868 }],
      publishedTime: PUBLISHED,
    },
    twitter: { card: "summary_large_image", title: c.title, description: c.description },
    robots: {
      index: true,
      follow: true,
      googleBot: { index: true, follow: true, "max-image-preview": "large" },
    },
  };
}

export default async function Page({
  params,
}: {
  params: Promise<{ locale: string }>;
}) {
  const { locale } = await params;
  const lang: Locale = isLocale(locale) ? locale : "en";
  if (!isLocale(locale)) notFound();
  const isDe = lang === "de";
  const canonical = publicUrl(lang, ROUTE);

  const headline = isDe
    ? "So funktioniert Beleg-OCR wirklich (und warum viele Scanner-Apps Fehler machen)"
    : "How Receipt OCR Actually Works (And Why Most Scanners Get It Wrong)";

  const jsonLd = {
    "@context": "https://schema.org",
    "@graph": [
      {
        "@type": "BreadcrumbList",
        itemListElement: [
          { "@type": "ListItem", position: 1, name: isDe ? "Start" : "Home", item: `${siteUrl}/${lang}` },
          { "@type": "ListItem", position: 2, name: "Blog", item: `${siteUrl}/${lang}/blog` },
          { "@type": "ListItem", position: 3, name: headline, item: canonical },
        ],
      },
      {
        "@type": "BlogPosting",
        "@id": canonical,
        headline,
        description: copy[lang].description,
        datePublished: PUBLISHED,
        dateModified: PUBLISHED,
        inLanguage: lang,
        mainEntityOfPage: canonical,
        image: `${siteUrl}/icon.png`,
        author: { "@type": "Organization", name: "ScanReceipts", url: siteUrl },
        publisher: {
          "@type": "Organization",
          name: "ScanReceipts",
          url: siteUrl,
          logo: { "@type": "ImageObject", url: `${siteUrl}/icon.png` },
        },
      },
    ],
  };

  return (
    <div className="flex min-h-screen flex-col bg-[#F6F9FF] text-[#161C22] font-sans">
      <script
        type="application/ld+json"
        dangerouslySetInnerHTML={{ __html: JSON.stringify(jsonLd).replace(/</g, "\\u003c") }}
      />
      <Header />
      <main className="flex-1 w-full py-16">
        <article className="max-w-3xl mx-auto px-4 sm:px-8">
          <div className="mb-8">
            <div className="flex items-center gap-2 mb-3">
              <span className="w-2.5 h-2.5 bg-black" />
              <span className="font-mono text-xs uppercase tracking-caps font-semibold text-[#475569]">
                {isDe ? "TECHNIK ERKLÄRT" : "TECHNICAL EXPLAINER"}
              </span>
            </div>
            <h1 className="font-display text-3xl sm:text-4xl lg:text-5xl font-bold tracking-tightest text-black leading-[1.05]">
              {headline}
            </h1>
            <p className="mt-4 font-mono text-xs uppercase tracking-caps text-[#64748B]">
              {isDe ? "Veröffentlicht am 19. August 2026" : "Published August 19, 2026"}
            </p>
          </div>

          <div className="mb-10 overflow-hidden border border-[#E2E8F0]">
            <Image
              src="/screenshot-inspector-review.png"
              alt={isDe ? "Screenshot: Der Inspector zeigt eine Validierungswarnung, wenn eine Summe nicht aufgeht" : "Screenshot: the receipt inspector flagging a validation warning when a total doesn't reconcile"}
              width={1295}
              height={868}
              className="w-full h-auto"
              priority
            />
          </div>

          {isDe ? (
            <div className="space-y-8 font-sans text-[#161C22] leading-relaxed">
              <p className="text-lg text-[#475569]">
                „OCR" klingt nach einer einzigen, klar definierten Technologie. In Wirklichkeit
                steckt hinter einem modernen Kassenbon-Scanner ein mehrstufiger Prozess – und genau
                an den Übergängen zwischen diesen Stufen passieren die Fehler, die einen Beleg-Scan
                später zum Problem in deinen eigenen Aufzeichnungen machen.
              </p>

              <section>
                <h2 className="font-display text-2xl font-bold tracking-tight text-black mb-3">
                  Was OCR und KI-Auslesung eigentlich tun
                </h2>
                <p className="mb-3">
                  Klassische OCR (Optical Character Recognition) erkennt einzelne Zeichen anhand
                  ihrer Form und setzt sie zu Wörtern zusammen – sie „liest" ein Bild im
                  buchstäblichen Sinn, versteht aber nicht, was sie liest. Moderne Beleg-Scanner
                  setzen stattdessen auf multimodale KI-Modelle, die ein Foto nicht nur als
                  Zeichenkette, sondern als strukturiertes Dokument interpretieren. Das Modell
                  erkennt: Das hier ist wahrscheinlich der Händlername, weil er oben und größer
                  steht. Das hier ist ein Datum, weil es dem Muster TT.MM.JJJJ folgt. Das hier ist
                  eine Artikelzeile mit Menge, Einzelpreis und Steuersatz, weil sie tabellarisch
                  unter einer Kopfzeile steht.
                </p>
                <p>
                  Dieser Kontext ist der entscheidende Unterschied zu reiner Zeichenerkennung: Ein
                  KI-Modell kann aus dem Layout eines Kassenbons ableiten, welche Zahl der
                  Gesamtbetrag ist und welche eine Zwischensumme, selbst wenn beide ähnlich
                  aussehen. Trotzdem bleibt es am Ende eine Vorhersage auf Basis von Pixeln – keine
                  Garantie.
                </p>
                <p className="mt-3">
                  Das gilt genauso für Rechnungen und Bewirtungsbelege, die deutlich komplexer
                  aufgebaut sind als ein einfacher Kassenbon: mehrere Steuersätze auf einer
                  Rechnung, ein separat ausgewiesenes Trinkgeld, oder eine Kopfzeile mit
                  Rechnungsnummer und Leistungszeitraum. Ein multimodales Modell muss hier nicht
                  nur einzelne Felder erkennen, sondern deren Beziehung zueinander verstehen – etwa
                  dass ein Trinkgeldbetrag zum Gesamtbetrag eines Bewirtungsbelegs addiert werden
                  muss, aber nicht Teil der Nettosumme ist. Genau an dieser Stelle unterscheiden
                  sich einfache OCR-Tools, die nur Text extrahieren, von einer echten
                  KI-Rechnungserkennung, die den Beleg als Ganzes interpretiert.
                </p>
              </section>

              <section>
                <h2 className="font-display text-2xl font-bold tracking-tight text-black mb-3">
                  Warum Thermopapier-Kassenbons so schwer zu lesen sind
                </h2>
                <p className="mb-3">
                  Die meisten deutschen Kassenbons werden auf Thermopapier gedruckt – dünn,
                  kontrastarm und empfindlich gegenüber Wärme und Licht. Für OCR-Systeme ergeben
                  sich daraus mehrere konkrete Probleme:
                </p>
                <ul className="list-disc pl-6 space-y-1 text-[#475569]">
                  <li>Verblassen: Nach wenigen Wochen im Portemonnaie wird der Druck grau statt schwarz, wodurch Zeichen mit dem Papierhintergrund verschmelzen.</li>
                  <li>Niedriger Kontrast: Selbst frische Thermodrucke haben oft weniger Kontrast als ein Laserdruck, was einzelne Ziffern verwechselbar macht.</li>
                  <li>Schräglage und Falten: Ein aus der Hand fotografierter Beleg ist selten perfekt gerade – Verzerrung erschwert die Zeilenerkennung zusätzlich.</li>
                  <li>Reflexionen und Schatten: Handyblitz oder Deckenlicht erzeugen Glanzstellen genau über wichtigen Zahlen.</li>
                </ul>
                <p className="mt-3">
                  Deshalb ist Bildvorverarbeitung vor der eigentlichen Erkennung so wichtig:
                  Kontrastanhebung, Entzerrung der Perspektive und Rauschunterdrückung verbessern
                  die Lesbarkeit spürbar, bevor das KI-Modell überhaupt zum Einsatz kommt. Ein
                  Scanner, der direkt das Rohfoto ungefiltert an das Modell weitergibt, arbeitet
                  bei schlechten Lichtverhältnissen spürbar unzuverlässiger.
                </p>
              </section>

              <section>
                <h2 className="font-display text-2xl font-bold tracking-tight text-black mb-3">
                  Warum reine KI-Erkennung bei Finanzdaten riskant ist
                </h2>
                <p className="mb-3">
                  Hier liegt der eigentliche Kern des Problems: Sprachmodelle und multimodale
                  KI-Modelle sind darauf trainiert, das plausibelste Ergebnis zu liefern – nicht
                  zwangsläufig das korrekte. Bei Fließtext fällt das kaum auf. Bei Zahlen auf einem
                  Kassenbon ist der Unterschied zwischen plausibel und korrekt aber bares Geld: Eine
                  „3" wird mit einer „8" verwechselt, zwei Ziffern werden vertauscht (aus 19,80 €
                  wird 91,80 €), oder ein Komma wird an der falschen Stelle gelesen. Solche Fehler
                  entstehen nicht aus Unachtsamkeit – sie sind eine strukturelle Eigenschaft von
                  Modellen, die Muster erkennen, aber nicht nachrechnen.
                </p>
                <p>
                  Das Tückische: Ein falsch erkannter Betrag sieht in der App genauso „fertig" aus
                  wie ein korrekt erkannter. Ohne zusätzliche Prüfung landet der Fehler unbemerkt in
                  deiner Tabelle – und fällt im schlechtesten Fall erst viel später auf, wenn du deine
                  eigenen Aufzeichnungen noch einmal durchgehst.
                </p>
              </section>

              <section>
                <h2 className="font-display text-2xl font-bold tracking-tight text-black mb-3">
                  Der deterministische Rechen-Check: der eigentliche Unterschied
                </h2>
                <p className="mb-3">
                  Genau deshalb reicht „KI liest den Beleg" allein nicht aus. Was einen Kassenbon
                  Scanner tatsächlich vertrauenswürdig macht, ist ein zweiter, unabhängiger Schritt:
                  eine deterministische, klassisch programmierte Rechenlogik, die jede von der KI
                  erkannte Summe nachrechnet – kein weiteres KI-Modell, sondern einfache,
                  nachvollziehbare Arithmetik in TypeScript. Konkret wird geprüft:
                </p>
                <ul className="list-disc pl-6 space-y-1 text-[#475569]">
                  <li>Ergibt Netto plus die ausgewiesene Mehrwertsteuer (7 % oder 19 %) exakt den Bruttobetrag?</li>
                  <li>Stimmt die Summe aller erkannten Einzelposten mit dem Gesamtbetrag auf dem Beleg überein?</li>
                  <li>Passen die einzelnen Steuerbeträge zu den jeweils angegebenen Steuersätzen?</li>
                </ul>
                <p className="mt-3">
                  Geht diese Rechnung nicht auf, wird der Beleg nicht stillschweigend übernommen,
                  sondern zur manuellen Prüfung markiert. Das ist ein grundlegend anderer Ansatz als
                  bei einem „naiven" KI-Wrapper, der der Modellausgabe blind vertraut: Die KI liest,
                  die Mathematik kontrolliert. Für Finanzdaten, bei denen ein einzelner
                  Zifferndreher echte Konsequenzen hat, ist genau diese zweite Instanz der
                  entscheidende Unterschied zwischen einem Scanner, der „meistens stimmt", und
                  einem, dessen Zahlen tatsächlich belastbar sind.
                </p>
              </section>

              <section>
                <h2 className="font-display text-2xl font-bold tracking-tight text-black mb-3">
                  Welche Felder ein Beleg-Scanner wirklich auslesen sollte
                </h2>
                <p className="mb-3">
                  „Der Beleg wurde erkannt“ ist keine brauchbare Aussage. Entscheidend ist, welche
                  Felder als eigene Datenpunkte herauskommen – und welche nur irgendwo im
                  Fließtext mitlaufen. Für eine Tabelle, die du später filtern, summieren oder
                  weitergeben kannst, braucht es mindestens: Händlername, Belegdatum, Bruttobetrag,
                  Nettobetrag, ausgewiesene Steuer (bei deutschen Belegen oft 7 % und 19 %
                  nebeneinander), Zahlungsart wenn erkennbar, und die einzelnen Artikelzeilen mit
                  Menge und Einzelpreis.
                </p>
                <p className="mb-3">
                  Dazu kommen Felder, die nur bei bestimmten Belegtypen zählen. Eine Rechnung braucht
                  eine Rechnungsnummer und oft ein Leistungsdatum, das vom Rechnungsdatum abweicht.
                  Ein Bewirtungsbeleg braucht Trinkgeld und einen Anlass – ohne diese zwei Angaben
                  ist der Scan zwar „vollständig“ als Einkauf, aber unbrauchbar als Dokumentation
                  eines Geschäftsessens. Genau deshalb ist ein{" "}
                  <SeoLink lang={lang} to="ocr">
                    spezialisierter Beleg-OCR-Scanner
                  </SeoLink>{" "}
                  etwas anderes als ein generisches Texterkennungs-Tool: Er kennt diese Felder als
                  eigene Spalten, nicht als Textbrocken.
                </p>
                <p>
                  Wenn du einen Scanner testest, nimm bewusst drei verschiedene Belege: einen
                  Thermokassenbon vom Supermarkt, eine PDF-Rechnung eines Software-Abos und einen
                  Restaurantbeleg mit Trinkgeld. Wenn bei allen dreien dieselben Felder sauber
                  getrennt ankommen, ist die Erkennung wirklich dokumentorientiert. Wenn nur der
                  Gesamtbetrag stimmt und der Rest als unsortierter Text landet, hast du OCR – aber
                  keine strukturierte Auslesung.
                </p>
              </section>

              <section>
                <h2 className="font-display text-2xl font-bold tracking-tight text-black mb-3">
                  So fotografierst du einen Kassenbon, damit OCR eine Chance hat
                </h2>
                <p className="mb-3">
                  Viele Fehlscans entstehen nicht im Modell, sondern schon beim Foto. Ein
                  halbzerknitterter Bon unter gelbem Küchenlicht, mit Daumen über der Summe, ist
                  für jedes System eine Zumutung. Die gute Nachricht: Ein paar einfache
                  Aufnahmeregeln heben die Trefferquote spürbar, unabhängig davon, welche App du
                  nutzt.
                </p>
                <ul className="list-disc pl-6 space-y-1 text-[#475569]">
                  <li>Lege den Beleg flach auf eine einfarbige, dunklere Fläche – nicht auf eine gemusterte Tischdecke.</li>
                  <li>Fotografiere von oben, nicht schräg von der Seite. Perspektive verzerrt Zeilen und macht Tabellen schwerer lesbar.</li>
                  <li>Vermeide Blitz direkt von vorn: Auf Thermopapier erzeugt er oft einen weißen Fleck genau über dem Gesamtbetrag.</li>
                  <li>Der gesamte Bon muss im Bild sein, inklusive der letzten Zeile mit der Summe. Abgeschnittene Enden sind die häufigste Ursache für „Summe fehlt“.</li>
                  <li>Bei sehr langen Kassenbons zwei Fotos machen statt eines unscharfen Panoramas – besser zwei scharfe Bilder als eines, auf dem die untere Hälfte verwackelt ist.</li>
                </ul>
                <p className="mt-3">
                  Wer Belege direkt an der Kasse fotografiert, statt sie erst in der Jackentasche
                  zerknüllen zu lassen, umgeht gleichzeitig das Verblassen. Mehr dazu, warum dieser
                  Moment der richtige Zeitpunkt ist, steht im Guide{" "}
                  <SeoLink lang={lang} to="organize">
                    Belege digitalisieren und organisieren
                  </SeoLink>
                  .
                </p>
              </section>

              <section>
                <h2 className="font-display text-2xl font-bold tracking-tight text-black mb-3">
                  Typische Fehlablesungen – und warum sie so teuer sind
                </h2>
                <p className="mb-3">
                  Nicht jeder OCR-Fehler ist gleich schlimm. Ein falsch erkannter Artikelname ist
                  ärgerlich. Ein falsch erkannter Betrag ist ein Buchungsfehler. Die häufigsten
                  Ziffernverwechslungen auf Thermopapier sind 3 und 8, 1 und 7, 5 und 6, plus
                  vertauschte Dezimalstellen. Aus 19,80 € wird 91,80 €. Aus 4,90 € wird 49,00 €.
                  Solche Fehler fallen in einer fertigen Tabelle nicht auf, weil die Zahl
                  „plausibel“ aussieht – sie ist nur falsch.
                </p>
                <p className="mb-3">
                  Ein zweiter Fehlertyp ist strukturell: Das Modell verwechselt Zwischensumme und
                  Gesamtbetrag, oder es behandelt das Trinkgeld als eigenen Einkauf. Bei
                  Mischsteuersätzen – 7 % auf Lebensmittel, 19 % auf Non-Food im selben Bon –
                  landet oft nur ein Satz in der Tabelle. Genau hier hilft keine bessere
                  Zeichenerkennung, sondern Layoutverständnis plus Nachrechnung. Wenn Netto plus
                  Steuer nicht zum Brutto passt, muss das System stoppen, nicht „ungefähr“
                  weitermachen.
                </p>
                <p>
                  Deshalb ist die Frage an jeden Scanner nicht „Wie oft liegt die KI richtig?“,
                  sondern „Was passiert, wenn sie falsch liegt?“. Eine ehrliche Antwort lautet:
                  Der Beleg wird markiert, und du siehst welche Summe nicht aufgeht. Eine
                  unehrliche Antwort lautet: Die Zahl steht trotzdem in der Excel-Datei. Den
                  Unterschied merkst du erst, wenn du später{" "}
                  <SeoLink lang={lang} to="excelGuide">
                    den Kassenbon in Excel auswerten
                  </SeoLink>{" "}
                  willst und die Monatssumme nicht zum Kontoauszug passt.
                </p>
              </section>

              <section>
                <h2 className="font-display text-2xl font-bold tracking-tight text-black mb-3">
                  Foto, PDF-Rechnung, mehrseitig: nicht jeder Beleg ist ein Kassenbon
                </h2>
                <p className="mb-3">
                  Ein Supermarktbon ist ein schmales, niedrig aufgelöstes Thermobild. Eine
                  Adobe- oder AWS-Rechnung ist ein sauberes, mehrseitiges PDF mit Tabellen,
                  Rechnungsnummer, Leistungszeitraum und oft einer anderen Währung. Beides
                  „Beleg-OCR“ zu nennen, verdeckt, dass die Pipeline unterschiedlich arbeiten
                  muss. Beim Foto zählt Vorverarbeitung. Beim PDF zählt, die richtige Tabelle zu
                  finden und nicht die Zahlungsbedingungen oder den Footer als Positionen zu
                  lesen.
                </p>
                <p>
                  Wer beides im selben Workflow haben will – Tankbeleg vom Vormittag, SaaS-Rechnung
                  am Nachmittag – braucht einen Scanner, der Dokumenttypen nicht in getrennte Apps
                  aufteilt. Für Selbstständige ist das der Normalfall, nicht die Ausnahme. Wie sich
                  das im Alltag anfühlt, wenn du nicht mehr abtippst, steht im Vergleich{" "}
                  <SeoLink lang={lang} to="scanningVsManual">
                    Kassenbon scannen statt abtippen
                  </SeoLink>
                  .
                </p>
              </section>

              <section>
                <h2 className="font-display text-2xl font-bold tracking-tight text-black mb-3">
                  Worauf du bei der Auswahl eines Scanners achten solltest
                </h2>
                <p className="mb-3">
                  Wenn du einen Beleg- oder Rechnungsscanner testest, lohnt sich ein gezielter Blick
                  auf genau diese Punkte: Wird das Bild vor der Erkennung optimiert? Werden
                  unklare oder unlesbare Werte offen markiert statt geraten? Und – am wichtigsten –
                  gibt es einen nachvollziehbaren Rechen-Check nach der KI-Erkennung, oder musst du
                  der Ausgabe des Modells blind vertrauen? Genau diese Kombination aus optimierter
                  Bildvorverarbeitung, multimodaler KI-Erkennung und deterministischem Math-Check
                  steckt hinter dem{" "}
                  <SeoLink lang={lang} to="ocr">
                    ScanReceipts Beleg-OCR-Scanner
                  </SeoLink>
                  .
                </p>
                <p>
                  Ein letzter Praxistest, den kaum jemand macht: denselben Beleg zweimal scannen.
                  Wenn Händler, Datum und Betrag identisch herauskommen, ist das ein gutes
                  Zeichen. Wenn sich die Summe um ein paar Cent verschiebt, arbeitet das System
                  wahrscheinlich ohne feste Nachrechnung – und genau dann ist es für Finanzdaten
                  das falsche Werkzeug.
                </p>
              </section>

              <section>
                <h2 className="font-display text-2xl font-bold tracking-tight text-black mb-3">
                  Häufige Fragen zur Beleg-OCR
                </h2>
                <div className="space-y-4">
                  <div>
                    <h3 className="font-display text-lg font-bold text-black mb-1">
                      Reicht klassische OCR wie Tesseract für Kassenbons?
                    </h3>
                    <p>
                      Für gedruckte A4-Seiten oft ja. Für zerknitterte Thermobons mit gemischten
                      Steuersätzen in der Regel nein. Klassische OCR liefert Text, aber keine
                      zuverlässige Zuordnung, welche Zahl der Gesamtbetrag ist.
                    </p>
                  </div>
                  <div>
                    <h3 className="font-display text-lg font-bold text-black mb-1">
                      Warum erkennt die App meinen verblassten Bon nicht?
                    </h3>
                    <p>
                      Wenn der Kontrast zwischen Schrift und Papier unter eine gewisse Schwelle
                      fällt, fehlen dem Modell die Pixel, aus denen es Ziffern ableiten kann. Dann
                      ist Raten schlimmer als ein klarer Hinweis „unlesbar“. Fotografiere Belege
                      deshalb noch am selben Tag.
                    </p>
                  </div>
                  <div>
                    <h3 className="font-display text-lg font-bold text-black mb-1">
                      Muss ich der KI trotzdem jede Summe glauben?
                    </h3>
                    <p>
                      Nein. Gute Scanner rechnen Netto, Steuer und Brutto unabhängig nach und
                      markieren Abweichungen. Das ist der Unterschied zwischen „schnell erfasst“
                      und „brauchbar für die eigene Tabelle“.
                    </p>
                  </div>
                </div>
              </section>

              <section>
                <h2 className="font-display text-2xl font-bold tracking-tight text-black mb-3">
                  Selbst ausprobieren
                </h2>
                <p>
                  Mehr zur konkreten Umsetzung findest du auf der Seite zu unserem{" "}
                  <SeoLink lang={lang} to="ocr">
                    KI-gestützten OCR-Kassenbon-Scanner
                  </SeoLink>
                  . Wenn du vor allem die fertige Tabelle brauchst, nimm den Guide{" "}
                  <SeoLink lang={lang} to="excelGuide">
                    Kassenbon in Excel umwandeln
                  </SeoLink>
                  . Oder probiere{" "}
                  <SeoLink lang={lang} to="home">
                    ScanReceipts
                  </SeoLink>{" "}
                  direkt aus und lass deinen nächsten Kassenbon von KI auslesen und rechnerisch
                  gegenprüfen, statt ihn blind einer App zu glauben.
                </p>
              </section>
            </div>
          ) : (
            <div className="space-y-8 font-sans text-[#161C22] leading-relaxed">
              <p className="text-lg text-[#475569]">
                "OCR" gets used as a catch-all term, but a modern receipt scanner is really a
                multi-stage pipeline — and the errors that make a receipt scan unreliable for
                your own records tend to happen at the seams between those stages, not in some single
                obvious failure point.
              </p>

              <section>
                <h2 className="font-display text-2xl font-bold tracking-tight text-black mb-3">
                  What OCR and AI extraction actually do
                </h2>
                <p className="mb-3">
                  Traditional OCR (Optical Character Recognition) recognizes individual characters
                  by shape and assembles them into words — it "reads" an image literally, without
                  understanding what it's reading. Modern receipt scanners instead lean on
                  multimodal AI models that interpret a photo as a structured document rather than
                  a string of characters. The model infers: this is probably the merchant name,
                  because it's positioned at the top in larger text. This is a date, because it
                  matches a date-like pattern. This is a line item with quantity, unit price, and
                  tax rate, because it sits in a tabular block under a header row.
                </p>
                <p>
                  That contextual reasoning is the real advance over plain character recognition —
                  it lets a model infer which number is the grand total versus a subtotal purely
                  from layout, even when the two numbers look similar. But it's still a prediction
                  based on pixels, not a guarantee.
                </p>
              </section>

              <section>
                <h2 className="font-display text-2xl font-bold tracking-tight text-black mb-3">
                  Why thermal-paper receipts are genuinely hard to read
                </h2>
                <p className="mb-3">
                  Most retail receipts are printed on thermal paper — thin, low-contrast, and
                  sensitive to heat and light. That creates several concrete problems for any OCR
                  system:
                </p>
                <ul className="list-disc pl-6 space-y-1 text-[#475569]">
                  <li>Fading: after a few weeks in a wallet, thermal print turns from black to gray, and characters start blending into the paper background.</li>
                  <li>Low native contrast: even a fresh thermal print typically has less contrast than laser or inkjet output, making similar digits easy to confuse.</li>
                  <li>Skew and creases: a receipt photographed handheld is rarely perfectly flat or square, and distortion makes line detection harder.</li>
                  <li>Glare and shadows: a phone flash or overhead light frequently creates a hotspot directly over the numbers that matter most.</li>
                </ul>
                <p className="mt-3">
                  That's why image preprocessing before the actual recognition step matters so
                  much: boosting contrast, correcting perspective skew, and reducing noise
                  meaningfully improve legibility before an AI model ever sees the image. A scanner
                  that feeds a raw, unprocessed photo straight into a model tends to degrade
                  noticeably in poor lighting.
                </p>
              </section>

              <section>
                <h2 className="font-display text-2xl font-bold tracking-tight text-black mb-3">
                  Why AI-only extraction is risky for financial data
                </h2>
                <p className="mb-3">
                  This is the real core of the problem. Language and multimodal models are trained
                  to produce the most plausible output — not necessarily the correct one. In
                  ordinary text, that rarely matters. In numbers on a receipt, the gap between
                  "plausible" and "correct" is literally money: a "3" gets misread as an "8," two
                  digits get transposed (19.80 becomes 91.80), or a decimal point lands in the wrong
                  place. These aren't careless mistakes — they're a structural property of models
                  built to recognize patterns, not to verify arithmetic.
                </p>
                <p>
                  The dangerous part is that a misread amount looks just as "finished" in the app as
                  a correctly read one. Without an additional check, the error slides silently into
                  your own records, and in the worst case only surfaces much later when you're
                  reviewing them yourself.
                </p>
              </section>

              <section>
                <h2 className="font-display text-2xl font-bold tracking-tight text-black mb-3">
                  The deterministic arithmetic check: the actual differentiator
                </h2>
                <p className="mb-3">
                  This is exactly why "AI reads the receipt" isn't a complete answer on its own.
                  What actually makes a receipt scanner trustworthy for your own records is a second,
                  independent step: a deterministic, plainly-coded arithmetic check that
                  re-verifies every total the AI extracted — not another AI model, just
                  straightforward, auditable TypeScript math. Concretely, it checks:
                </p>
                <ul className="list-disc pl-6 space-y-1 text-[#475569]">
                  <li>Does the net amount plus the stated tax equal the gross total, exactly?</li>
                  <li>Do all the extracted line items sum to the receipt's stated total?</li>
                  <li>Does each tax amount match the tax rate it's supposedly calculated from?</li>
                </ul>
                <p className="mt-3">
                  When the numbers don't reconcile, the receipt isn't silently accepted — it's
                  flagged for manual review instead. That's a fundamentally different approach from
                  a naive AI wrapper that trusts the model's output at face value: the AI reads, the
                  math checks. For financial data, where one transposed digit has real consequences,
                  that second, independent pass is what separates a scanner that's "usually right"
                  from one you can actually trust.
                </p>
              </section>

              <section>
                <h2 className="font-display text-2xl font-bold tracking-tight text-black mb-3">
                  Which fields a receipt scanner should actually extract
                </h2>
                <p className="mb-3">
                  "The receipt was recognized" is not a useful claim. What matters is which fields
                  come out as their own data points — and which ones just float around in a blob of
                  text. For a spreadsheet you can later filter, sum, or hand off, you need at least:
                  merchant name, receipt date, gross total, net amount, the stated tax (on German
                  receipts often 7% and 19% side by side), payment method when it's visible, and
                  every line item with quantity and unit price.
                </p>
                <p className="mb-3">
                  Then there are fields that only matter for certain document types. An invoice
                  needs an invoice number and often a service period that is not the same as the
                  invoice date. A business-meal receipt needs a tip and an occasion — without those
                  two, the scan is "complete" as a purchase and useless as a record of a client
                  dinner. That is why a{" "}
                  <SeoLink lang={lang} to="ocr">
                    specialized receipt OCR scanner
                  </SeoLink>{" "}
                  is different from a generic text-recognition tool: it treats those fields as
                  columns, not as leftover text.
                </p>
                <p>
                  When you evaluate a scanner, use three different documents on purpose: a thermal
                  grocery receipt, a PDF invoice from a software subscription, and a restaurant
                  receipt with a tip. If all three come back with the same fields cleanly
                  separated, the extraction is actually document-aware. If only the total is
                  right and everything else arrives as unsorted text, you have OCR — but not
                  structured extraction.
                </p>
              </section>

              <section>
                <h2 className="font-display text-2xl font-bold tracking-tight text-black mb-3">
                  How to photograph a receipt so OCR has a chance
                </h2>
                <p className="mb-3">
                  A lot of failed scans are not the model's fault. They start with the photo. A
                  half-crumpled slip under yellow kitchen light, with a thumb over the total, is a
                  bad input for any system. The good news: a few simple shooting habits raise
                  accuracy a lot, no matter which app you use.
                </p>
                <ul className="list-disc pl-6 space-y-1 text-[#475569]">
                  <li>Lay the receipt flat on a plain, darker surface — not a patterned tablecloth.</li>
                  <li>Shoot from directly above, not from an angle. Perspective warps rows and makes tables harder to read.</li>
                  <li>Avoid a flash pointed straight at the paper: on thermal stock it often blows out a white patch right over the total.</li>
                  <li>The whole slip has to be in the frame, including the last line with the sum. Cropped bottoms are the most common reason a total is "missing."</li>
                  <li>For very long receipts, take two sharp photos instead of one blurry panorama — two clean images beat one where the lower half is smeared.</li>
                </ul>
                <p className="mt-3">
                  Photographing the receipt at the register, instead of letting it crumple in a
                  pocket first, also sidesteps fading. More on why that moment is the right time
                  is in the guide{" "}
                  <SeoLink lang={lang} to="organize">
                    how to digitize and organize receipts
                  </SeoLink>
                  .
                </p>
              </section>

              <section>
                <h2 className="font-display text-2xl font-bold tracking-tight text-black mb-3">
                  Typical misreads — and why they are expensive
                </h2>
                <p className="mb-3">
                  Not every OCR error is equally bad. A mangled item name is annoying. A mangled
                  amount is a bookkeeping error. The most common digit swaps on thermal paper are
                  3 and 8, 1 and 7, 5 and 6, plus shifted decimal points. $19.80 becomes $91.80.
                  $4.90 becomes $49.00. Those mistakes do not stand out in a finished spreadsheet
                  because the number still looks "plausible" — it is just wrong.
                </p>
                <p className="mb-3">
                  A second error type is structural: the model confuses a subtotal with the grand
                  total, or treats the tip as its own purchase. On mixed tax rates — 7% on food,
                  19% on non-food on the same slip — often only one rate lands in the table. Better
                  character recognition will not fix that. Layout understanding plus arithmetic
                  will. If net plus tax does not equal gross, the system has to stop, not "roughly"
                  continue.
                </p>
                <p>
                  So the question to ask any scanner is not "How often is the AI right?" It is
                  "What happens when it is wrong?" An honest answer: the receipt is flagged, and
                  you see which total does not reconcile. A dishonest answer: the number still
                  lands in the Excel file. You notice the difference only later, when you try to{" "}
                  <SeoLink lang={lang} to="excelGuide">
                    turn the receipt into a spreadsheet
                  </SeoLink>{" "}
                  and the monthly sum does not match the bank statement.
                </p>
              </section>

              <section>
                <h2 className="font-display text-2xl font-bold tracking-tight text-black mb-3">
                  Photo, PDF invoice, multi-page: not every receipt is a till slip
                </h2>
                <p className="mb-3">
                  A grocery receipt is a narrow, low-contrast thermal image. An Adobe or AWS
                  invoice is a clean, multi-page PDF with tables, an invoice number, a service
                  period, and often a different currency. Calling both "receipt OCR" hides that
                  the pipeline has to work differently. On a photo, preprocessing matters. On a
                  PDF, the hard part is finding the right table and not reading the payment terms
                  or the footer as line items.
                </p>
                <p>
                  Anyone who wants both in the same workflow — a fuel receipt in the morning, a
                  SaaS invoice in the afternoon — needs a scanner that does not split document
                  types across separate apps. For freelancers that mix is the default, not the
                  exception. What the day feels like when you stop retyping is in{" "}
                  <SeoLink lang={lang} to="scanningVsManual">
                    receipt scanning vs. manual data entry
                  </SeoLink>
                  .
                </p>
              </section>

              <section>
                <h2 className="font-display text-2xl font-bold tracking-tight text-black mb-3">
                  What to look for when evaluating a receipt scanner
                </h2>
                <p className="mb-3">
                  If you're testing a receipt or invoice scanner, it's worth checking specifically
                  for these things: does it preprocess the image before extraction? Does it flag
                  unclear or unreadable values instead of silently guessing? And — most importantly
                  — is there a traceable arithmetic check after the AI pass, or are you trusting the
                  model's raw output? That combination of image preprocessing, multimodal AI
                  extraction, and a deterministic math cross-check is exactly what's running behind
                  the{" "}
                  <SeoLink lang={lang} to="ocr">
                    ScanReceipts receipt OCR scanner
                  </SeoLink>
                  .
                </p>
                <p>
                  One last practical test almost nobody runs: scan the same receipt twice. If
                  merchant, date, and amount come back identical, that is a good sign. If the
                  total drifts by a few cents, the system is probably running without a fixed
                  arithmetic check — and then it is the wrong tool for financial data.
                </p>
              </section>

              <section>
                <h2 className="font-display text-2xl font-bold tracking-tight text-black mb-3">
                  Common questions about receipt OCR
                </h2>
                <div className="space-y-4">
                  <div>
                    <h3 className="font-display text-lg font-bold text-black mb-1">
                      Is classic OCR like Tesseract enough for receipts?
                    </h3>
                    <p>
                      For printed A4 pages, often yes. For crumpled thermal slips with mixed tax
                      rates, usually no. Classic OCR returns text, not a reliable mapping of which
                      number is the grand total.
                    </p>
                  </div>
                  <div>
                    <h3 className="font-display text-lg font-bold text-black mb-1">
                      Why does the app fail on my faded receipt?
                    </h3>
                    <p>
                      Once contrast between ink and paper drops below a certain point, the model
                      no longer has the pixels it needs to infer digits. Guessing is worse than a
                      clear "unreadable" flag. Photograph receipts the same day you get them.
                    </p>
                  </div>
                  <div>
                    <h3 className="font-display text-lg font-bold text-black mb-1">
                      Do I still have to trust the AI on every total?
                    </h3>
                    <p>
                      No. A good scanner independently recomputes net, tax, and gross and flags
                      mismatches. That is the difference between "captured quickly" and "usable in
                      your own spreadsheet."
                    </p>
                  </div>
                </div>
              </section>

              <section>
                <h2 className="font-display text-2xl font-bold tracking-tight text-black mb-3">
                  Try it yourself
                </h2>
                <p>
                  For more on the implementation, see our{" "}
                  <SeoLink lang={lang} to="ocr">
                    AI-powered OCR receipt scanner
                  </SeoLink>
                  . If what you want is the finished table, use the guide{" "}
                  <SeoLink lang={lang} to="excelGuide">
                    receipt to Excel
                  </SeoLink>
                  . Or try{" "}
                  <SeoLink lang={lang} to="home">
                    ScanReceipts
                  </SeoLink>{" "}
                  directly and let AI extraction and an arithmetic cross-check handle your next
                  receipt, instead of taking a scanner's word for it.
                </p>
              </section>
            </div>
          )}

          <RelatedReading
            lang={lang}
            keys={["ocr", "excelGuide", "organize", "scanningVsManual"]}
          />
        </article>
      </main>
      <Footer />
    </div>
  );
}
