Ich hab da mal eine Idee. Wie viele großartige Erfindungen mögen wohl mit genau diesem Satz begonnen haben? Auch unsere Idee eines einheitlichen Formats für Rechnungsdaten hat das Potential, deinen Arbeitsalltag zu revolutionieren. Davon sind wir überzeugt. Und du?
Das Problem
Als Billomat-Nutzer schreibst du Rechnungen. Logisch. Aber sehr wahrscheinlich bekommst du auch Rechnungen von Dienstleistern, Lieferanten oder sonstigen Unternehmen, die deine Kohle haben wollen. Und genau hier kommt unsere Idee ins Spiel. Für deinen Computer ist die Rechnung nicht viel mehr als ein Stück Papier, eine bunte Bilddatei oder bestenfalls eine willkürliche Zeichenanordnung in einem PDF-Dokument. Um es auf den Punkt zu bringen: Rechnungen sind dumm!
Das hat zur Folge, dass du unweigerlich den Inhalt für eine Gewinn- und Verlust-Rechnung abtippen musst. Auch eine Suche nach allen Telefonrechnungen, bei denen der Rechnungsbetrag eine gewisse Summe überstieg, ist nicht möglich. Kurz: Der Inhalt der Rechnung ist maschinell nicht erfassbar. Auch Texterkennungen schlagen sich hier mehr schlecht als recht und sind einfach im Detail zu fehleranfällig.
Die Lösung
Was aber wäre, wenn in der Rechnung maschinenlesbare Informationen stecken würden? Diese „sprechenden“ Rechnungen könnten problemlos eingelesen und weiterverarbeitet werden. Die Buchhaltungssoftware importiert mit einem Klick die Rechnung und kennt sofort alle Posten, das Fälligkeitsdatum und die enthaltenen Steuern. Oder dein E-Mail-Client erkennt die Rechnung und öffnet mit einem Klick ein Online-Banking-Fenster, bei dem Betrag, Empfänger und Verwendungszweck schon vorausgefüllt sind. Oder Dropbox erinnert daran, dass eine Rechnung, die dort abgelegt wurde, morgen fällig wird. Die Anwendungsfälle sind vielseitig.
Wohin damit?
Auch die Frage, wo sich solche Daten verstecken sollten, ist leicht beantwortet. So ziemlich jedes Dateiformat besitzt Meta-Daten. Dies sind Informationen, die das Dokument beschreiben und für den Otto-Normalverbraucher nicht sichtbar sind. Dort stehen in der Regel Autor, Erstellungsdatum oder bei Fotos Kamerainformationen wie Belichtungszeit oder geografische Koordinaten des Aufnahmeorts. Hier hätten standardisierte Rechnungsdaten problemlos Platz. Auf dem guten alten Papier können die Daten als QR-Code untergebracht werden.
Wir sind nicht allein
All das wäre sinnlos, wenn nur Billomat ein solches Format im Alleingang etablieren wollte. Ein erster Entwurf eines solchen Formats für den Austausch von Rechnungsdaten wird deshalb gleich von einer Reihe deutscher Startups erarbeitet. Neben einiger unserer Mitbewerber sind bereits eine Finanzbuchhaltung, diverse Online-Archivierungs-Dienste und Online-Speicher sowie Dokumentenmanagement-Systeme mit an Bord. Auch CRM-Anbieter haben Interesse bekundet. Zusammen soll ein Format verabschiedet werden, das es ermöglicht, dass Rechnungen kinderleicht von einem Dienst zum nächsten gereicht werden und dieser gleich weiß, was drin steht.
Ein „wir“ bezieht sich also ausdrücklich nicht nur auf Billomat, sondern auf eine Gruppe innovativer Köpfe aus den unterschiedlichsten Bereichen.
Alter Hut?
Eine wichtige Frage ist, ob es das nicht schon gibt. Immerhin ist die Idee zu gut, um noch nicht umgesetzt worden zu sein. Zusammen haben wir einige vorhandene Formate gesichtet und untersucht. Oftmals haben sie ihre Wurzel im Enterprise-Bereich und sind für diesen Zweck einfach zu kompliziert, aufgeblasen und akademisch. Mitunter wird alleine für die Einsicht in Spezifikationen aus den Achtzigern ein ordentlicher Geldbetrag verlangt.
Das kann nicht sein!
Ein solches Format muss offen, schlank und zweckdienlich sein. Deutschland hat genug Startups zu bieten, die mit frischen Ideen am selben Strang ziehen können, um so Großes zu schaffen. Offen und unentgeltlich für alle.
Jetzt du!
So weit, so gut. Jetzt brauchen wir dich. Was hältst du von der Idee? Gibt es das schon? Was wäre ein cooler Name für ein solches Format?
Die wichtigste Frage aber ist die, wie du dir vorstellen kannst, wie dein Arbeitsalltag von einem solchen Datenaustausch geprägt sein könnte? In welchen Diensten oder mit welchen Werkzeugen verwendest du Rechnungen? Wo hast du dich schon immer geärgert, dass du Rechnungen abtippen musst? Und welche sinnvolle Verarbeitung ist so verrückt, dass es noch nicht gedacht wurde? Hilf mit, Rechnungen eine Stimme zu geben und damit den Workflow ein wenig smarter zu machen! Mit sechs einfachen Worten: „Ich hab da mal eine Idee“.
Update
Jetzt ist es amtlich. Der Standard wird docTag heißen. Weitere Infos werden im Laufe der Zeit unter http://doctag.org folgen. Dort findest du auch eine Liste der Unternehmen, die bereits mit an dem Standard arbeiten.
Deutsch »

Sehr geile Idee,
gerade für den Austausch Dropbox / Lex…ähh..Buchhaltungssoftware / E-Mail. Bin mal gespannt ob sich das durchsetzen wird.
Kennen tue’ ich’s jedenfalls noch nicht.
Zum Ablauf:
Ich erhalte meine Rechnungen in Outlook (2007, bald 2010) – druck mir das PDF aus für die Ordner im Schrank, schiebe die Mail samt Anhang in den Ordner “Rechnungen”. Alle paar Tage überweise ich dann manuell die angefallenen Rechnungsposten.
Sobald mir ein Name einfällt sag’ ich Bescheid :)
lg
Es gibt IMHO schon Standards, welche in diese Richtung gehen. Schaut z.B. mal hier: http://de.m.wikipedia.org/wiki/EDIFACT
Gruß aus Bremen
EDIFACT ist ein Standard, der ursprünglich aus den 80ern stammt und entsprechend verstaubt und komplex wirkt.
Mit dem Wissen und Erfahrung über Schnittstellen, APIs und Datenformate, welche das heutige Web mit seinen Mashups erst möglich gemacht hat, ist ein solcher Dino extrem unsexy.
Wir wollen genau an dieser Stelle ansetzen und den Datenaustausch so einfach machen, dass der Standard auch von einer sehr breiten Masse genutzt werden kann.
Sinnvoll für meine account kunden!
Gute Idee, wenn es alle umsetzen können, die daran beteiligt sind.
Mein derzeitiger Workflow sieht so aus, dass ich die Rechnungen per Post/Mail bekomme und die Rechnungen scanne (Fujitsu ScanSnap mit Mac) und anschließend in DevonThink importiere. Dort wird sie nach Jahr und Eingang/Ausgang abgelegt. Evtl. wird sie noch mit Markern getagged (Bezahlt, Reklamiert, …). Da die PDFs Volltextindiziert sind, ist eine einfach Suche möglich. Bessere Aggregierungsfunktionen aber nicht (Durchschnitt der Telefonrechnungen der letzten Quartale, …).
Natürlich drucke ich die Rechnungen parallel noch für die Buha aus und leg sie schön im Ordner ab.
Toll wäre ein Format, das neben den Rechnungs eigenen Daten (Betrag, Kunde, evtl. Projekt, Fälligkeitsdatum, Betrag, Skontistaffelungen inkl. Fälligkeiten) noch weitere Möglichkeiten bietet. Die Buha könnte schon Vorkontierungen an der Rechnugn speichern (Pos. 1 Konto 4711, Pos. 2 Konto 0815). Das würde eine Zentrale Speicherung notwendig machen (bzw. nen MD5 über das Dokument legen und die Metadaten zum MD5 zentral speichern oder so).
Na ja, ihr werdet das schon machen, bin auf die Resultate gespannt :)
Hallo,
kann doch gar nicht so schwer sein dafür ein XML zu definieren. (wenn sowas nicht schon gibt) auf die Rechnungen kommt ein kleiner QR-Code drauf welcher die url zum XML vom Server des Rechnungsleger enthält. (die daten direkt im QR ablegen wird sich nicht ausgehen, oder der QR wäre riesig)
Hätte zusätzlich den Vorteil das man über XSLT immer noch wandeln könnte falls ein anbieter die Einhaltung der Definition nicht sogenau nimmt.
my2c
Ludwig
Ja richtig. Schwer ist das tatsächlich nicht. Es muss halt nur mal jemand machen.
Angedacht ist übrigens nicht XML, sondern JSON. Das lässt sich ebenso einfach in vielen Programmiersprachen verarbeiten und ist ein wenig kürzer, weil der Overhead geringer ist.
Beim QR-Code überlegen wir, ob dieser nicht einfach eine URL enthält, unter der die Daten dann abgelegt sind.
Letztlich wird die Spezifikation, die langsam immer konkreter wird, keine Raketenwissenschaft sein. Und genau das macht sie ja so praktisch.
Nachtrag: In österreich gibt es sowas: http://www.ebinterface.at/standard.html
Sehr gute Idee!
Passt auch zu Eurem Partner iOutbank.
@Markus: Mit dem Overhead hast du sicher recht, aber dafür hast du mit xml möglcihkeiten die du in einem serialisierten object nicht hast. Die von mir schon angesprochene einfache Umwandlung mittels XSLT fällt zb. vollständig weg.
Hab mir das schema von ebinterface mal angesehen. ( http://www.ebinterface.at/schema/3p02/Invoice.xsd ) das deckt schon wirklich alle fälle ab und ist auch nicht wirklcih kompliziert wenn man nur das notwendigste will. Warum auch das rad neu erfinden. (und das sag ich nicht nur weil ich als Österreicher davon profitieren würde :-)
In DE dürftet ihr einen ziemlichen wildwuchs haben. siehe http://www.ibi.de/e-rechnung.html
zum QR code, ja natürlich nur als url, wie geschrieben wird die informations menge für einen QR zu groß sein.
egal wie ihr es macht, viel erfolgt dabei.
Ludwig
Hallo,
A) Habt Ihr Euch auch Rechnungsmail angeschaut: http://www.rechnungsmail.de ?
B) Wie kann ich an dem Projekt mitwirken? Ich würde den Standard gern in unsere Rechnungs-App für Salesforce CRM bill.ON einbauen.
Viele Grüße
Marko
Ja, rechnungsmail.de kennen wir. Der Nachteil an dieser Lösung ist, dass zum einen der Kreis der Unterstützer recht gering ist, dass es auf die deutsche Sprache beschränkt ist und sich nur auf den E-Mail-Versand beschränkt.
Wir möchten das Thema aber viel allgemeiner und umfassender angehen.
Sehr gerne kann bei dem Projekt mitgewirkt werden. Je mehr Unterstützer, desto besser! In den kommenden Tagen werden wir eine Projekt-Webseite aufsetzten, auf welcher wir das Prozedere erklären werden.
Infos dazu folgen hier im Blog.
Moin
Interessante Diskussion! Wäre es nicht ggf. sinnvoller eine (halb) automtische Extrahierung der Rechnungsdaten aus dem OCR erkannten Text der Rechnung zu extrahieren?
GGf. sollte man hier eine genügende Genauigkeit erreichen können. Lernende Filter könnten auf die verschiedenen Rechnungen die man bekommt trainiert werden.
Sebastian
…wenn es “einfach” sein soll, dann würden mich in der ersten Realisierungsstufe eh nur die Kopfdaten der Rechnung interessieren (Datum, Lieferant, Bruttosumme, Umsatzsteuersatz, optional Umsatzsteuer-ID), also das “Nötigste”, was bei der Fibu-Software eingegeben werden muss.
Etwa: {rdatum:12032012;ldatum:120312;firma:Müller-Lüdenscheidt GmbH und CoKG, summe:1223,89;usatz:0.19;id:23049802938502}
Optional, falls nicht zu lang, oder halt bis zur Grenze, noch {r_pos1:mp3-player;r_pos2:Panasonic TV40PDPIHFK} hinzufügen.
Eine zusätzlich URL sehe ich erst mal nicht, da die Firmen dann eine entsprechende Security-Policy Umsetzen müssten, auch um sich selber zu schützen, immerhin kann man dann ja die Umsatzhistorie einer Firma ausspähen.
Für den ersten Schritt in Richtung “Eckdaten abtippen” sollte es m.E. reichen.
genau darum geht es, ein papierlosoes büro zu haben, das man in der cloud backupt und das in der cloud verwaltet wird, also meins teuerberater kann schon auf meine dropbox zugreifen, aber wenn er gleich die zahlen in den rechnungen, etc. verwerten kann, brauche ich ihn nach einer gewissen zeit gar nicht mehr…
bzw. seine zeit für mich wird so reduziert dass ich auch hier geld sparen kann…
loslegen, bitte!
ich bin dafür!!!
für die Elektronische Rechnungsübermittlung gibt es verschiede Möglichkeiten, EDIfact, Opentrans (XML) oder auch Systemspezifische (zb SAP) möglichkeiten.
je nach Programmiergeschickt ist es relativ leicht solche Schnittstellen zu nutzen.
das problem liegt so denke ich rein bei den Papierrechnungen, und (PDF ohne Metainformationen)
da hilft dann kein XML oder sonstiges, weil dann wieder wie auch schon als Problem beschrieben, eine Onlinschnittstelle zum Versender vorhanden sein muss.
so finde ich die Möglichkeit mit QR Code als die große Chance,
ein QR Code kann alle relevanten Daten erhalten, die man für die Buchhaltungserfassung zb braucht und die Lösung wäre perfekt.
so träume ich schon seit 20 Jahren von der Möglichkeit vielleicht sogar den Kassenzettel vom Supermarkt so ähnlich zu erfassen.
schön wäre es natürlich wenn man Rechnungen Online mit den Metainformationen zb als XML oder ähnlich erhält. auch vom Supermarkt.
ich beschäftige mich mit Online Auftragsadminstration für Vereine und auch in diese richtung wäre eine solch QR Code normierung ideal.
bitte um weitere Informationen
auch in Österreich wäre das wichtig.
vielleicht ein interessantes Beispiel für Json nutzung für Rechnungen
https://hilfe.hudora.de/entries/305482-edihub-api-rechungsabruf-invoic
Vielen Dank schon mal für das umfangreiche und gute Feedback. Eure Anmerkungen werden auf jeden Fall in die Überlegungen einfließen.
Viel wichtiger als das eigentliche Format ist aus meiner Sicht aber die Idee, Meta-Daten in der Rechnung zu speichern. Viele Formate laufen als Austauschformat parallel zum Dokument. Bei unserer Idee sind Dokument und Daten ein und das selbe. Wenn man also das Dokument verschickt (egal ob per Mail, FTP oder auf einem USB-Stick), bleiben die auslesbaren Daten darin erhalten. Das ist beispielsweise ein Unterschied zu rechnungsmail.de, wo die Daten im Medium (also lesbar im Mailtext) und nicht (unsichtbar) im Dokument enthalten sind. Wenn ich das Dokument dann ohne die Mail weitergebe, sind alle Vorteile hinüber.
Lange Rede, kurzer Sinn: Vielen lieben Dank fürs Mitdenken. Wir halten euch auf dem Laufenden.
So, nun gibt es das erste Update:
Der Standard wird docTag heißen. Unter http://doctag.org wird es im Laufe der Zeit weitere Infos dazu geben. Wir sind froh, dass bereits 12 Unternehmen am selben Strang ziehen und schon weitere Firmen Interesse bekundet haben.
Wir sind uns sicher: DocTag wird spitze!