So extrahieren Sie Rechnungsdaten von Lieferanten
für E-Commerce-SKU-Margen
Auf r/AmazonSeller beschrieb ein FBA-Verkäufer seinen COGS-Workflow: „Ich verwende SVERWEISE und ähnliches, um meine Excel-Datei im Laufe des Monats zu aktualisieren, und am Ende brauche ich 3–4 Stunden, um die COGS zu berechnen.“ Unter E-Commerce-Händlern mit 50 bis 200 SKUs ist das kein Ausreißer – es ist die Norm. Der Engpass ist nicht die Mathematik. Es ist das Extrahieren der Zahlen aus Lieferantenrechnungen. Alibaba sendet eine PDF-Handelsgarantierechnung mit 12 Positionen auf Chinesisch und Englisch. Ein 1688-Lieferant screenshotet per WhatsApp eine handschriftliche Proforma. Eine Fabrik mailt eine mehrseitige Handelsrechnung mit nach Kartons aufgeschlüsselten Versandkosten. Jedes Format hinterlegt dieselben Daten – SKU, Stückkosten, Menge, Fracht – in einem anderen Layout, und jemand muss sie extrahieren, bevor die Tabelle überhaupt geöffnet wird.
Wichtige Erkenntnisse
- Drei bis vier Stunden pro Monat – das ist das Sichtbare: Tippen, S-Verweise, Tab-Wechsel – und das ist die billigste Folge manueller Lieferantenrechnungserfassung für Ihr E-Commerce-Unternehmen.
- Der teure Teil bleibt unsichtbar: Wenn Fracht, Zölle und Bearbeitung aus vier separaten Dokumenten nie pro SKU zugeordnet werden, klafft eine Lücke von 46 % zwischen Ihren erfassten Produktkosten und den tatsächlichen Einstandskosten – und jede Preisentscheidung, die Sie seitdem getroffen haben, trägt diesen Fehler in sich.
- ImageToTable.ai liest alle Ihre Lieferantenformate – Alibaba-PDF, WhatsApp-Screenshot, Werksproforma – über eine einzige Spaltendefinition und gibt die pro SKU berechneten Einstandskosten bereits während der Extraktion aus – keine Vorlagen pro Lieferant erforderlich.
Warum sich Lieferantenrechnungen im E-Commerce von normalen AP-Rechnungen unterscheiden
Kreditorenbuchhaltung bearbeitet Rechnungen, um sie zu bezahlen. Die relevanten Felder – Rechnungsnummer, Lieferantenname, Gesamtbetrag, Fälligkeitsdatum – sind universell. Aber ein E-Commerce-Händler, der eine Lieferantenrechnung prüft, denkt nicht zuerst an die Zahlung. Er denkt: Was hat mich dieses Produkt tatsächlich gekostet?
Die Daten, die ein E-Commerce-Unternehmen aus einer Lieferantenrechnung benötigt, gehen tiefer als reine Zahlungsinformationen. Sie brauchen den SKU-Code – sei es der interne Code des Lieferanten, Ihr eigener SKU oder eine ASIN. Sie brauchen den Großhandelspreis pro Einheit, der als „FOB-Preis", „EXW-Stückpreis" oder einfach „单价" (Chinesisch für Stückpreis) erscheinen kann. Sie brauchen die unverbindliche Preisempfehlung (UVP), falls angegeben, und die Mindestbestellmenge (MOQ), um zu prüfen, ob Sie in einer sinnvollen Mengenstufe eingekauft haben. Sie brauchen die Vorlaufzeit – die Anzahl der Tage zwischen Bestellung und Lieferung – denn ein Lieferant, der 30 Tage zusagt und in 45 liefert, zehrt leise an Ihrem Working Capital. Und Sie brauchen all dies pro SKU, pro Bestellung, für jeden Lieferanten, mit dem Sie zusammenarbeiten.
Kreditorenbuchhaltungssoftware ist für das erste Problem konzipiert – haben wir den richtigen Betrag an den richtigen Lieferanten gezahlt? Diese Frage endet beim Rechnungsgesamtbetrag. Die Frage nach der E-Commerce-Marge beginnt auf Positionsebene und hört nicht auf.
Die Felder, die jeder E-Commerce-Produktkosten-Tracker benötigt
Bevor Sie einen Extraktions-Workflow einrichten, legen Sie fest, was extrahiert werden soll. Die folgende Spaltenliste ist für das E-Commerce-Kosten-Tracking konzipiert – nicht für die AP-Rechnungsverarbeitung. Dies sind die Felder, die in ein SKU-basiertes Margenblatt einfließen:
| Spaltenname | Wo es auf Lieferantenrechnungen erscheint | Warum es für die Margenanalyse wichtig ist |
|---|---|---|
| SKU / Produktcode | Artikelnummer des Lieferanten, ASIN oder Ihre interne SKU – bezeichnet als „Artikel-Nr.", „货号", „Modell-Nr." oder in Produktbeschreibungen eingebettet | Der Schlüssel, der diese Rechnungszeile mit Ihrem Bestands- und Verkaufsdaten verbindet |
| Produktname | Kann nur auf Chinesisch („不锈钢水瓶500ml"), Chinesisch+Englisch oder nur auf Englisch erscheinen | Bestätigt, dass die SKU dem richtigen physischen Produkt zugeordnet ist |
| Großhandelspreis pro Einheit | „FOB-Preis", „EXW-Stückpreis", „单价" oder „Stückpreis" – kann in USD, RMB oder der lokalen Währung des Lieferanten angegeben sein | Die Basis für alle Margenberechnungen; die Währung muss notiert werden |
| UVP | Nicht immer aufgeführt; falls vorhanden, bezeichnet als „UVP", „Verkaufspreis", „建议零售价" | Schnelle Plausibilitätsprüfung Ihrer Preisgestaltung – ist Ihr Verkaufspreis wettbewerbsfähig gegenüber der Herstellerempfehlung? |
| Bestellte Menge | „Menge", „Bestellmenge", „数量" | Bestätigt, ob der Lieferant das Bestellte versandt hat |
| Erhaltene Menge | Nicht immer auf der Rechnung — manchmal nur auf dem Packzettel oder Lieferschein | Abweichung zwischen bestellter und erhaltener Menge löst eine Kostenanpassung aus |
| MOQ | „MOQ“, „Mindestbestellmenge“, „起订量“ — oft eine artikelbezogene Zahl im Angebot, nicht auf jeder Rechnung | Erfasst, ob Sie in optimaler Menge einkaufen; ein unter dem MOQ gekaufter Artikel hat in der Regel einen Aufpreis |
| Lieferzeit (Tage) | „Lieferzeit“, „交货期“ oder berechnet aus Bestelldatum vs. Versanddatum | Kennzahl für Lieferantenzuverlässigkeit — sinkende Lieferzeiten über mehrere Bestellungen lösen eine Anpassung des Meldebestands aus |
| Lieferantenname | Firmenname im Rechnungskopf; chinesische Lieferanten verwenden oft einen anderen rechtlichen Firmennamen als ihren Alibaba-Shop-Namen | Entscheidend für die Gruppierung von Kostendaten nach Lieferant und den Leistungsvergleich zwischen Anbietern |
| Versand-/Frachtkosten | „Fracht“, „Versand“, „运费“ – kann als Gesamtbetrag pro Rechnung, pro Karton oder als Teil einer Position erscheinen | Bestandteil der Landed Cost; muss auf einzelne SKUs verteilt werden |
| Einfuhrzölle & Gebühren | Selten auf der Lieferantenrechnung – meist auf einer separaten Rechnung des Zollagenten oder Spediteurs | Ein weiterer Bestandteil der Landed Cost, der nach der Extraktion zu den Stückkosten hinzugerechnet werden muss |
| Bestelldatum | „Rechnungsdatum“, „Bestelldatum“, „日期“ | Ermöglicht Trendanalysen – steigen die Kosten für dieselbe SKU im Laufe der Zeit? |
| Zahlungsbedingungen | „Bedingungen“, „Zahlung“, „付款条件“ – 30 % Anzahlung / 70 % vor Versand, Netto 30 usw. | Liquiditätsplanung – ein Wechsel des Lieferanten von 30/70 auf 50/50 verändert Ihren Working-Capital-Zeitplan |
Sie benötigen nicht jedes Feld auf jeder Rechnung. Die relevanten sind die, die Ihre Margenformel speisen. Ein Dropshipper, der nie Inventar anfasst, braucht keine erhaltene Menge. Ein FBA-Verkäufer, der Container aus Shenzhen importiert, benötigt alle oben genannten plus die zusammengeführten Daten der Zollmaklerrechnung. Definieren Sie die Spalten, die Ihrer Kostenstruktur entsprechen, und lassen Sie das Extraktionstool den Rest ausfüllen.
Vom Einkauf bis zu den Einfuhrnebenkosten: Die fehlende Verbindung in der E-Commerce-Buchhaltung
Ein Szenario, das sich täglich in E-Commerce-Unternehmen abspielt: Ein FBA-Händler bestellt 1.000 Einheiten einer Edelstahl-Wasserflasche zu 3,50 $ FOB bei einem Lieferanten in Shenzhen. Er verbucht 3.500 $ als Produktkosten. Drei Wochen später stellt der Spediteur 850 $ für die Seefracht in Rechnung. Ein Zollmaklerbeleg über 262,50 $ Zollgebühren (7,5 % des Warenwerts) trifft ein. Die Sendung verbringt zwei Wochen in einem 3PL-Eingangslager zu 0,30 $ pro Einheit. Die Tabelle des Händlers zeigt Produktkosten von 3,50 $. Tatsächlich kosten die Produkte 5,12 $ – eine Differenz von 46 %.
Das sind die Einfuhrnebenkosten, und gemäß IRS Publication 334 müssen Frachtkosten, Einfuhrabgaben und Handlingskosten in den Lagerbestand aktiviert werden – sie sind Teil der Herstellungskosten (COGS), keine separaten Betriebsausgaben. Die einheitlichen Aktivierungsvorschriften des IRS (Pub 334, Abschnitt zu Uniform Capitalization Rules) verlangen, dass diese indirekten Kosten in die Bemessungsgrundlage der zum Weiterverkauf erworbenen Güter einfließen. Sie werden über die COGS zurückgewonnen, wenn die Einheit verkauft wird – sofern sie überhaupt erfasst wurden.
Die Formel für die Einfuhrnebenkosten ist einfach:
Einfuhrnebenkosten pro Einheit = (Großhandelspreis + Fracht + Zollgebühren + Versicherung + Prüfung + Handling + Lagerung) ÷ Einheiten pro Sendung
Die Berechnung an sich ist nicht schwer. Die Zahlen an einem Ort zusammenzubekommen schon. Lieferantenrechnungen enthalten den Großhandelspreis. Speditionsrechnungen die Versandkosten. Zollabrechnungen die Zölle. 3PL-Rechnungen die Lagerkosten. Vier Dokumente, vier Formate, drei verschiedene Unternehmen – und du brauchst sie alle in derselben Tabellenzeile, bevor die Formel greift. Die meisten E-Commerce-Händler lösen das, indem sie Zahlen aus vier separaten PDFs manuell in eine Excel-Zeile eintragen – pro Sendung, pro SKU. Bei 20 Sendungen pro Quartal mit durchschnittlich 8 SKUs sind das 160 Zeilen manuelle Dateneingabe. Jedes Quartal.
Ein E-Commerce-Händler in der r/FulfillmentByAmazon-Community beschrieb die Realität: „Sobald man mehr als ein paar SKUs hat, wird der tatsächliche Produktpreis unübersichtlich.“ Die Verwirrung ist nicht konzeptionell – Händler verstehen den Landed Cost. Die Verwirrung ist verfahrenstechnisch: Die Zahlen leben in verschiedenen Dokumenten, und sie an einem Ort zusammenzubekommen erfordert Tipparbeit.
Wenn du Lieferantenrechnungsdaten mit KI extrahierst, kannst du berechnete Spalten nutzen, um die Landed-Cost-Berechnung während der Extraktion durchzuführen – die KI liest den Großhandelspreis aus der Lieferantenrechnung, addiert den von dir als Parameter eingegebenen Frachtbetrag, wendet einen Zollsatz an und gibt die Stückkosten (Landed Cost) direkt aus. Kein separater Tabellenschritt. Die Ausgabespalte heißt „Landed Cost pro Einheit“ und die Zahl darunter ist bereit für deine Margenformel. Eine vollständige Anleitung zu den Extraktionsgrundlagen findest du in unserem vollständigen Leitfaden zur Rechnungsdatenextraktion.
So funktioniert der Extraktions-Workflow
Hier der Schritt-für-Schritt-Prozess, ausgelegt für jemanden mit einem Ordner voller Lieferantenrechnungen, der eine Margen-Tabelle benötigt – keine AP-Automatisierung. Ziel ist es, in einer Sitzung aus einem Stapel gemischter Dokumente eine einzige Excel-Datei zu erstellen.
Dateien werden sicher verarbeitet und nicht gespeichert.
Ziehen Sie jedes Format hinein, das Sie haben – Alibaba-PDF-Handelsgarantierechnungen, 1688-Screenshots aus WeChat, eingescannte Proformarechnungen von Fabriken, Speditionsrechnungen, Zollagentenabrechnungen. Sie können eine Mischung aus PDFs, JPGs und PNGs in einem Durchgang hochladen. Die KI liest jedes Dokument unabhängig – Ihre Lieferanten müssen nicht alle das gleiche Rechnungslayout verwenden. Ein Verkäufer, der 30 SKUs über vier Lieferanten verwaltet, kann einen ganzen Quartalsbestand an Rechnungen auf einmal hochladen. Wenn Sie den Workflow testen, beginnen Sie mit Rechnungen von zwei verschiedenen Lieferanten – einer Alibaba-PDF, einer Fabrik-Proforma – um zu sehen, wie eine Spaltenliste Daten aus beiden extrahiert.
Das unterscheidet semantische KI-Extraktion von templatebasierter OCR. Statt auf jeder Lieferantenrechnung Felder manuell zu markieren, geben Sie einfach die gewünschten Spaltennamen ein – „SKU", „Produktname", „Einstandspreis pro Einheit", „Bestellmenge", „Lieferant", „Bestelldatum", „Frachtkosten". Die KI findet jeden Wert, indem sie die Bedeutung des Feldes versteht. Eine SKU kann auf einer Alibaba-Rechnung als „Item No", auf einem 1688-Screenshot als „货号" oder in einer Produktbeschreibung auf einer Werksproforma auftauchen. Drei verschiedene Positionen, drei verschiedene Bezeichnungen – eine Spaltendefinition erfasst alle. Das ist Custom Column Extraction: Sie geben Spaltennamen ein, und die KI füllt Zeilen, indem sie passende Werte in jedem Dokument findet – ohne Vorlagen, ohne lieferantenspezifische Konfiguration, ohne layoutabhängige Regeln.
Definieren Sie eine berechnete Spalte wie „Landed Cost pro Einheit (Einstandspreis pro Einheit + (Frachtkosten / bestellte Menge) + (Einstandspreis pro Einheit × 0,075))“ – ersetzen Sie dabei Ihren tatsächlichen Zollsatz. Die KI extrahiert den Einstandspreis, liest die Frachtzuordnung und führt die Berechnung während der Verarbeitung durch. Wenn die Ausgabedatei geöffnet wird, ist die Spalte „Landed Cost“ bereits befüllt – keine nachträglichen Formeln nötig. Sie können auch eine abgeleitete Spalte verwenden, wenn Ihre Lieferantenrechnungen unterschiedliche Währungscodes verwenden: Legen Sie die Spalte so an, dass sie in einer einzigen Währung ausgibt, mit einer Regel, die die korrekte Umrechnung anwendet.
Download als XLSX. Jede Rechnungszeile hat dieselben Spalten, unabhängig davon, ob die Quelle eine Alibaba Trade Assurance-PDF, ein Proforma-Scan einer Fabrik oder ein WhatsApp-Screenshot eines 1688-Lieferanten war. Kein Zusammenführen lieferantenspezifischer Dateien. Kein Kopieren und Einfügen zwischen Tabellen. Eine Ausgabedatei, bereit für die Margenanalyse. Für größere Mengen verarbeitet die Stapelverarbeitung von Rechnungen hunderte Dokumente mit denselben Spaltendefinitionen, Seiten in 5–10 Sekunden pro Stück — etwa 18-mal schneller als die manuelle Eingabe einer einzelnen Seite.
Warum Rechnungsformate von Lieferanten eine besondere Herausforderung darstellen
Vorlagenbasierte OCR-Tools gleichen ein Dokument mit einem bekannten Layout ab. Sie trainieren das Tool: „Die Rechnungsnummer steht immer oben rechts in diesem PDF.“ Das funktioniert, wenn Sie jeden Monat Rechnungen desselben Lieferanten verarbeiten. Aber die Lieferantenbeziehungen im E-Commerce funktionieren anders:
- Alibaba Trade Assurance-Rechnungen folgen Alibabas eigenem Format mit separaten Abschnitten für Produktdetails, Versand und Zahlungsschutz – sauber, aber anders als jedes andere Lieferantenlayout.
- 1688-Lieferanten-Screenshots sind oft Handyfotos des 1688-Bestellbildschirms mit Produktnamen auf Chinesisch, Stückpreisen in RMB und Bestellmengen – für Menschen lesbar, aber es existiert kein strukturiertes PDF.
- Proforma-Rechnungen von Fabriken variieren je nach Fabrik. Manche verwenden eine formelle Vorlage mit Firmenbriefkopf, Incoterms und Bankdaten. Andere sind eine Tabelle in einem Word-Dokument, das als PDF exportiert wurde. Wieder andere sind handschriftlich und fotografiert.
- Speditionsrechnungen werden pro Sendung abgerechnet, nicht pro Artikel, und müssen mit den Lieferantenrechnungsdaten zusammengeführt werden – die Frachtkosten müssen auf die Artikel dieser Sendung verteilt werden.
- Dropshipping-Lieferantenrechnungen von AliExpress oder Shein-verbundenen Lieferanten kommen oft als Screenshots mit Produktnamen in einer Mischung aus Englisch und Chinesisch – „Chinglish“-Beschreibungen, die ein Mensch versteht, die aber ein keywordbasiertes OCR-Tool falsch interpretiert.
Ein vorlagenbasiertes Tool benötigt für jedes Layout eine separate Vorlage. Vier Lieferanten bedeuten vier Vorlagen. Ein neuer Lieferant – eine neue Vorlage. Ein Lieferant aktualisiert sein Rechnungsformat – die Vorlage ist defekt und liefert stillschweigend unvollständige Ergebnisse, bis es jemand bemerkt. Bei 8–10 aktiven Lieferanten – typisch für einen wachsenden E-Commerce-Shop – übersteigt der Wartungsaufwand für Vorlagen den Zeitgewinn durch Automatisierung.
Semantische Extraktion umgeht dieses Problem vollständig. Die KI liest eine Rechnung so wie ein Einkaufsleiter: Sie sieht ein Dokument mit Produkten, Preisen, Mengen und Daten. Sie verlässt sich nicht auf Koordinaten oder Label-Abgleiche. Sie versteht, dass „单价 ¥23.50“ auf einem 1688-Screenshot und „Unit Price $3.50“ auf einer Alibaba-Rechnung dasselbe Feld sind – nur in unterschiedlichen Sprachen und an unterschiedlichen Positionen. Dieser Ansatz ermöglicht, dass ein einziger Satz Spaltennamen für alle Lieferanten funktioniert und einheitliche Extraktion über Formate hinweg ohne lieferantenspezifische Konfiguration möglich wird.
Der entscheidende Unterschied: Vorlagenbasierte Extraktion vervielfacht den Einrichtungsaufwand mit jedem neuen Lieferanten. KI-basierte Extraktion hält den Aufwand konstant. Für einen E-Commerce-Shop, der 2–3 neue Lieferanten pro Jahr aufnimmt, ist das der Unterschied zwischen einem skalierbaren Workflow und einem, der irgendwann zugunsten manueller Erfassung aufgegeben wird.
Von der Tabelle zum Margen-Dashboard
Sobald Lieferantenrechnungsdaten in einer strukturierten Tabelle vorliegen, wird die Margenanalyse, die zuvor ein vierteljährliches Ratespiel war, zu einem Live-Datensatz. So sieht das in der Praxis aus:
Bruttomarge pro SKU ist jetzt eine Formel, die aus Zellen abgerufen wird, keine Zahl, die Sie jeden Monat manuell neu berechnen. Verkaufspreis minus Landed Cost pro Einheit, geteilt durch Verkaufspreis. Eine SKU, die bei einem Großhandelspreis von 3,50 $ profitabel aussah, könnte nach Abzug der Landed Cost von 5,12 $ eine Marge von 12 % offenbaren – unter den 15-20 % Minimum, das die meisten FBA-Verkäufer anstreben, um Amazon-Gebühren zu decken. Ohne Extraktion erfolgt diese Berechnung einmalig manuell, wenn Sie daran denken. Mit Extraktion ist sie jedes Mal live, wenn Sie die Tabelle aktualisieren. Wie der CFO eines Amazon-Verkäufers auf Reddit anmerkte: "Sobald Sie mehr als ein paar SKUs haben, wird der tatsächliche Produktkosten verwirrend." Extraktion ist das, was die Verwirrung beseitigt.
Amazon-FBA-Verkäufer profitieren zusätzlich: Produktkosten werden von Versandkosten getrennt. Amazon berechnet Empfehlungsgebühren (meist 15 %), FBA-Versandgebühren, Lagergebühren und Werbekosten – nichts davon erscheint auf einer Lieferantenrechnung. Eine SKU-basierte Extraktionstabelle hält die lieferantenseitigen Kosten (Großhandel, Fracht, Zölle) in einem Satz Spalten, während Sie Amazon-seitige Kosten in einem anderen Satz ergänzen können. So sehen Sie die Marge auf zwei Ebenen: Produktmarge (Verkaufspreis minus Landed Cost) und Nettomarge nach Amazon-Gebühren. Ein Produkt mit 40 % Produktmarge, aber nur 8 % Nettomarge nach FBA-Gebühren erzählt eine andere Geschichte als eines mit 25 % Produktmarge und 18 % Nettomarge. Ohne den Extraktionsschritt, der präzise Landed-Cost-Daten liefert, sehen beide Produkte aus, als würden sie „3,50 $“ kosten – die wahre Margengeschichte bleibt verborgen.
Lieferanten-Performance-Tracking wird zum Nebenprodukt desselben Datensatzes. Lieferzeittrends – verlängert sich der durchschnittliche Lieferzeitraum von Lieferant A von 30 auf 38 Tage? Kostentrends – steigt der Stückpreis von Lieferant B schneller als der Kategoriedurchschnitt? MOQ-Einhaltung – bestellen Sie versehentlich unter der Mindestmenge einer SKU und zahlen einen unbemerkten Aufpreis? Diese Fragen sind aus einzelnen Rechnungen nicht zu beantworten. Aus einer strukturierten Tabelle, die jeden Bestellzyklus aktualisiert wird, sind sie leicht zu beantworten.
Und wenn sich Zollsätze ändern – wie in den Jahren 2025–2026 mehrfach geschehen, mit schwankenden US-Zolltarifsätzen des Harmonisierten Tarifschemas über Produktkategorien hinweg – können Sie mit bereits strukturierten Landed-Cost-Daten die Zollkomponente neu berechnen und sofort sehen, welche SKUs am stärksten betroffen sind. Ohne diese Struktur müssen Sie jede Lieferantenrechnung wieder aus dem Ordner holen und manuell neu kalkulieren.
FAQ
Funktioniert das auch mit chinesischen Lieferantenrechnungen?
Ja. Die KI liest chinesische, englische und gemischtsprachige Dokumente. Ein 1688-Lieferanten-Screenshot mit Produktnamen auf Chinesisch („不锈钢保温杯"), Preisen in RMB und Mengen in arabischen Ziffern wird genauso verarbeitet wie eine englischsprachige Alibaba Trade Assurance-Rechnung. Die von Ihnen auf Englisch definierten Spaltennamen – „SKU", „Produktname", „Großhandelspreis" – werden zu den Kopfzeilen, und die KI extrahiert die entsprechenden Werte unabhängig von der Ausgangssprache. Wenn eine chinesische Rechnung einen Preis mit „¥23,50" angibt, erkennt die KI, dass dies der Wert für Ihre Spalte „Großhandelspreis" ist, und extrahiert ihn.
Kann ich Daten aus Screenshots extrahieren, nicht nur aus PDFs?
Ja. Das Tool akzeptiert JPG-, PNG- und PDF-Eingaben. Handy-Screenshots aus WhatsApp oder WeChat – üblich bei 1688-Lieferanten, die Auftragsbestätigungen als Bilder versenden – werden genauso verarbeitet wie gescannte PDFs. Die KI liest den visuellen Inhalt des Bildes, nicht die eingebettete Textebene, daher funktioniert auch ein Foto eines Computerbildschirms mit dem internen System eines Lieferanten. Die Bildqualität ist entscheidend: Ein unscharfer Screenshot mit 480p-Auflösung liefert Extraktionen mit geringerer Zuverlässigkeit als ein klarer 1080p-Screenshot. Bei stark komprimierten Bildern können Strategien zur Extraktion niedriger Auflösung helfen.
Wie verteile ich Frachtkosten auf Artikel, wenn die Rechnung nur eine Gesamtsumme ausweist?
Die meisten Speditionsrechnungen zeigen nur eine Gesamtsumme pro Sendung, keine Aufschlüsselung nach Artikel. Sie haben drei Optionen: (1) Verwenden Sie eine berechnete Spalte, um die Frachtkosten durch die Gesamtmenge aller Artikel in der Sendung zu teilen – das ergibt eine gleiche Verteilung pro Einheit. (2) Verteilung nach Gewicht – falls Ihre Speditionsrechnung das Gesamtgewicht angibt, erstellen Sie eine berechnete Spalte, die den Frachtanteil jedes Artikels basierend auf Stückgewicht mal Menge ermittelt. (3) Verteilung nach Wert – höherwertige Artikel übernehmen einen proportional größeren Frachtanteil. Welche Methode sinnvoll ist, hängt von Ihrer Frachtstruktur ab: Gewichtsbasierte Verteilung eignet sich für Seefracht (Preis pro Container/Gewicht), wertbasierte für Luftfracht (Preis pro kg mit Wertzuschlag). Das Extraktionstool übernimmt die Berechnung, sobald Sie die Regel definiert haben. Sie benötigen keine artikelgenaue Aufschlüsselung vom Spediteur.
Was ist mit Zöllen – kommen die erst Monate später auf einer separaten Rechnung?
Das ist ein echtes Problem. Spediteure und Zollagenten stellen Zollrechnungen oft erst 3–6 Wochen nach der Zollabfertigung aus – manchmal, nachdem Sie die Ware bereits verkauft und die Herstellkosten verbucht haben. Der richtige Ansatz: Extrahieren Sie jetzt die Lieferantendaten aus der Rechnung, um Großhandelspreis und Frachtkosten in Ihre Tabelle zu übernehmen. Wenn die Zollrechnung eintrifft, erfassen Sie sie in einem separaten Tab mit Spalten wie „Sendungs-ID“, „Gezahlter Zoll“ und „Datum“. Nutzen Sie SVERWEIS oder INDEX-VERGLEICH, um den Zollbetrag in die Landed-Cost-Spalte der ursprünglichen Sendung zu übernehmen. So bleiben Ihre Margendaten auch bei verspätet eingehenden Kosten korrekt, ohne dass Sie wochenlang mit der Extraktion warten müssen. Wenn Sie die periodengerechte Buchhaltung anwenden, erwartet IRS Pub 334, dass geschätzte Landed Costs bei Wareneingang zurückgestellt und beim Eintreffen der tatsächlichen Rechnungen abgeglichen werden.
Lässt sich das mit QuickBooks oder Xero integrieren?
Das Tool exportiert Excel (XLSX), CSV und JSON. Sie können die extrahierten Daten herunterladen und in QuickBooks, Xero oder jede andere Buchhaltungsplattform importieren, die Dateiimporte unterstützt. Es gibt keine direkte API-Integration. Für E-Commerce-Verkäufer, die A2X oder ähnliche Tools zur Überbrückung von Amazon-Abrechnungen mit QuickBooks nutzen, dienen die vom Tool extrahierten Lieferantenkosten als COGS-Eingabe, die diese Tools nicht erfassen – Sie importieren die extrahierte Lieferantenrechnungstabelle als Journaleintrag oder Bestandskostenaktualisierung. Für Verkäufer, die Google Sheets zur Kostenverfolgung nutzen, ermöglicht das Google Sheets-Add-on die direkte Extraktion von Lieferantenrechnungsdaten in Ihr Tracking-Blatt, ohne Google Sheets verlassen zu müssen.
Wie viele Rechnungen kann ich auf einmal verarbeiten?
Sie können mehrere Rechnungen in einem Batch hochladen – das Tool verarbeitet jede Seite in 5-10 Sekunden. Es gibt keine feste Begrenzung der Batch-Größe, allerdings skaliert die Verarbeitungszeit linear mit der Seitenzahl. Ein Batch von 20 Rechnungen mit durchschnittlich 2 Seiten (insgesamt 40 Seiten) wird in etwa 3-7 Minuten verarbeitet. Die eigentliche Einschränkung ist nicht die Tool-Kapazität – sondern ob Sie Ihre Spaltennamen so definiert haben, dass sie alle benötigten Felder über alle Lieferanten im Batch abdecken. Für die Stapelverarbeitung großer Quartalsmengen bewältigt die Batch-Extraktion höhere Volumen effizient.
Die Tabelle ist der einfache Teil
Die meisten E-Commerce-Händler verstehen die Margenberechnung. Sie wissen: Landed Cost = Großhandelspreis + Fracht + Zölle + Gebühren. Sie wissen, dass sie dies pro SKU erfassen sollten. Das fehlende Glied in der Kette ist nicht das Wissen – es ist die Tatsache, dass die Daten in PDFs und Screenshots von einem Dutzend verschiedener Lieferanten stecken und für die Tabelle abgetippt werden müssen. Jeder Artikel zur Landed-Cost-Berechnung überspringt diesen Schritt. Er nennt die Formel und geht davon aus, dass die Zahlen bereits in einer Spalte stehen.
Tun sie nicht. Sie stehen in einem Alibaba Trade Assurance-PDF, einem 1688-Screenshot und einer Speditionsrechnung in drei verschiedenen Formaten. Die Extraktion ist der Schritt, der die Formel nutzbar macht. Sobald Sie Lieferantenrechnungsdaten in eine strukturierte Tabelle überführen können, ohne für jeden Lieferanten eine Vorlage zu erstellen, wird die Margenanalyse vom Quartalsprojekt zu etwas, das Sie nach jeder Lieferung in Minuten aktualisieren.
Keine Anmeldung erforderlich. Laden Sie eine Lieferantenrechnung hoch und definieren Sie Ihre Spalten.