PROLoyalty™ INVOICE verbindet eingereichte Kaufnachweise mit Ihrem Loyalty-Programm. Rechnungsdaten und Produkte werden geprüft und zugeordnet; bestätigte Vorgänge bilden die Grundlage für Punkte oder Cashback.
Ein Handwerksbetrieb kauft beim Großhandel. Der Hersteller sieht den Kauf nicht in seinem eigenen Shop – der eingereichte Beleg schafft eine zusätzliche, prüfbare Grundlage für das Bonusprogramm.
PROLoyalty INVOICE™ verbindet die Erfassung von Kopf- und Positionsdaten mit Produktmatching und Geschäftsregeln. Erst freigegebene Datensätze gehen an die vereinbarte Punkte-, Cashback- oder Weiterverarbeitung.
Das Beispiel zeigt, warum eine korrekt gelesene Summe allein nicht genügt: Eine geeignete Position, ein ausgeschlossener Artikel und ein unsicherer Treffer benötigen unterschiedliche Folgewege.
Beispiel-Fachhandel · Rechnung 001
Kaufzeitraum innerhalb der Beispielaktion
| Position | Zuordnung | Entscheidung |
|---|---|---|
| A · Aktionsprodukt | Katalogtreffer eindeutig | Geeignet · Regel erfüllt |
| B · Zubehör | Artikel erkannt | Ausgeschlossen · außerhalb des Sortiments |
| C · Abgekürzter Freitext | Mehrere Kandidaten | Nachprüfung · keine automatische Freigabe |
Die Erkennung eines Artikels und seine Teilnahme an einer Aktion sind zwei verschiedene Entscheidungen.
Ein Kaufnachweis gelangt über den vereinbarten Eingang in den Prozess und wird dem berechtigten Teilnehmer zugeordnet.
Rechnungsdatum, Händler, Positionen, Mengen und Beträge werden in strukturierte Daten überführt.
Artikelangaben werden mit dem Produktkatalog verglichen. Unsichere Zuordnungen bleiben als solche sichtbar.
Teilnahmeregeln entscheiden, ob eine erkannte Position für die Aktion qualifiziert ist. Sonderfälle gehen in die Prüfung.
Freigegebene Daten verbinden den Nachweis mit Punkten, Cashback, Registrierung oder einem angebundenen System.
OCR liest Zeichen aus einem Dokument. Für Loyalty muss daraus ein belastbarer Produktbezug mit passender Regelentscheidung entstehen. Ein gut erkannter Betrag beweist weder das Aktionsprodukt noch die Teilnahmeberechtigung.
Eingereichte Belege zeigen die tatsächlich erfassten Käufe. Sie sind kein automatischer Nachweis des vollständigen Einkaufsverhaltens eines Teilnehmers oder seines gesamten Share of Wallet.
Der vereinbarte Eingang verbindet Dokument, Teilnehmer und Programm. Der Nutzer erkennt, ob der Upload angekommen ist und ob noch Angaben fehlen.
Zugang, Dateigrenzen und unterstützte Formate werden je Umsetzung bestätigt.
Die öffentlich beschriebene Lösung unterstützt das direkte Auslesen eingebetteter ZUGFeRD-XML-Rechnungsdaten. Positionen, Mengen und Preise können strukturiert übernommen werden.
Dadurch entfällt für diese Daten der Umweg über OCR-Texterkennung.
Bei einem bildbasierten Eingang wird die geeignete Erkennung auf den konkreten Belegtyp abgestimmt. Schlechte Lesbarkeit und fehlende Seiten bleiben eigenständige Prüfgründe.
XRechnung oder weitere Formate werden nur im bestätigten Umfang zugesagt.
Die Erfassung orientiert sich am Programmzweck. Händler und Kaufdatum können den Aktionszeitraum und die Teilnahme bestimmen; Position, Menge und Artikelnummer ermöglichen den Katalogabgleich. Nicht benötigte Angaben werden im abgestimmten Prozess begrenzt. Dokumentzugriff und Aufbewahrungsdauer werden ausdrücklich festgelegt.
Artikelnummer, EAN und freie Bezeichnung können auf unterschiedlichen Rechnungen anders aussehen. Die Zuordnung zum eigenen Sortiment ist deshalb ein eigener fachlicher Schritt.
Der Katalog liefert die verlässlichen Produktinformationen. Ein erkannter Begriff wird nicht allein deshalb zum qualifizierten Kauf. Bei mehreren plausiblen Kandidaten braucht der Fall einen sichtbaren Prüfstatus und eine nachvollziehbare Entscheidung.
Ein eindeutiger Produktbezug kann nach den gültigen Regeln weiterverarbeitet werden. Ein unsicherer Treffer nennt den Klärungsbedarf. Ein nicht zuordenbarer Artikel bleibt außerhalb der automatischen Freigabe. Die fachliche Korrektur wird mit Grund und Referenz dokumentiert.
Produktänderungen und neue Händlerbezeichnungen können die Zuordnung beeinflussen. Katalogpflege und strukturierte Rückmeldungen aus dem Review helfen, die Datenbasis zu verbessern. Eine pauschale Erkennungsquote lässt sich daraus ohne repräsentative Belegstichprobe nicht ableiten.
Kaufzeitraum, teilnehmender Händler und zugeordneter Teilnehmer müssen die konkrete Aktion erfüllen. Ein spät eingereichter Beleg benötigt eine klare Fristregel.
Das Belegdatum und das Eingangsdatum sind unterschiedliche Daten.
Aktionssortiment, Varianten, Mindestmengen und Limits bestimmen den qualifizierten Anteil. Nicht geeignete Positionen bleiben begründet ausgeschlossen.
Eine Rechnung kann gleichzeitig geeignete und ausgeschlossene Positionen enthalten.
Wiederholte Einreichung und mögliche Missbrauchsindikatoren werden nach vereinbarten Regeln behandelt. Ein auffälliger Fall benötigt kontrolliertes Review.
Ein Indikator ist kein automatischer Beweis für Betrug.
Die Review-Oberfläche benötigt den relevanten Nachweis, erkannte Felder, Katalogzuordnung und Regelbegründung. Zuständige Rollen können einen unklaren Treffer korrigieren oder eine Position mit Grund ablehnen. Welche Entscheidung eine zweite Freigabe benötigt, folgt dem abgestimmten Workflow.
Belegdokument, extrahierte Felder und Buchungshistorie haben unterschiedliche Aufgaben. Zugriff wird auf den benötigten Bereich begrenzt. Aufbewahrung und Löschung werden mit Programmzweck und geltenden Anforderungen abgestimmt; ein Audit soll keine unnötigen sensiblen Belegdetails vervielfältigen.
Die veröffentlichte PRODATA-Produktbeschreibung sieht zwei Einsatzwege vor: innerhalb der ProLoyalty Enterprise Suite und als eigenständige Lösung mit angebundenen CRM- und ERP-Prozessen.
Für die dort genannten vorgefertigten Konnektoren zu Salesforce, SAP, DATEV, HubSpot und Pipedrive werden Datenfelder, Geschäftsregeln und Übergaben konkret abgestimmt. Der Name eines Konnektors ersetzt keine Prüfung des unterstützten Zielsystems und seiner Version.
Eine repräsentative Stichprobe umfasst typische Händler, Belegqualitäten, Positionen und Sonderfälle. Gemeinsam werden Soll-Ergebnisse für Erfassung, Matching, Ablehnung und Review festgehalten. Der Pilot bewertet korrekte Ergebnisse und praktikable Prüfung ebenso wie Laufzeit und Automatisierungsanteil.
Belegvolumen, Positionszahl, Datenqualität, Produktkatalog, Schnittstellen und gewünschte Betreuung bestimmen den Aufwand. Zusätzliche Eingänge, Formate oder Prüfmechaniken werden separat bestätigt. Zeitersparnis und Wirtschaftlichkeit werden am eigenen Szenario gemessen, nicht aus einem fremden Durchschnitt versprochen.
Besprechen wir Ihre Zielgruppe, Ihre Datenquellen und den Ablauf, den Sie verbessern möchten. Daraus entsteht eine Demo, die zu Ihrem Programm passt.
Ein normaler Vorgang. Ein Sonderfall. Die beteiligten Systeme. Wir zeigen, wie Regeln, Kanäle und Kontrolle zusammenspielen.
