Funktionen · Geld & Recht
Hier werden Rechnungen an Kunden geschrieben — mit oder ohne Kasse. Ein Vorgang beginnt oft mit einem Angebot, wird per Klick in eine Rechnung umgewandelt, als PDF (und als E-Rechnung im ZUGFeRD-Format) erzeugt, per Mail verschickt und danach im Blick behalten: Wer hat bezahlt, wer nicht, wer bekommt eine Mahnung. Wiederkehrende Beträge laufen als Abo und werden in einem Rechnungslauf automatisch erzeugt. Zu einer Rechnung gehören auch Lieferschein, Gutschrift und Storno. Dieser Bereich ist gleichzeitig das eigenständige Produkt dikas Faktura für Betriebe ohne Kasse — Handwerk, Beratung, Agentur, Freiberufler.
Rechnungen mit Status und Betrag verwalten.
Echte Oberfläche
Keine Stockmotive: Die Aufnahmen stammen aus den reproduzierbaren DiKAS-Demos und zeigen die jeweilige Funktion im Produkt.
Vollständiger Überblick
Alle folgenden Punkte stammen aus dem gegen den Programmcode geprüften Funktionskatalog.
Positionen, Rabatt, Zahlungsziel, Skonto, Rechnungsadresse; Bearbeiten nur im Entwurf. Der Adress-Schnappschuss führt Firma UND Person getrennt (BillingCompanyName/BillingName); Vorgabe für „Name" ist Customer.BillingPersonName (die Person, ersatzweise der Anzeigename) — nicht DisplayName, der bei Firmenkunden die Firma liefert (s. Falle unten)
Filtern nach Kunde, Status, Zeitraum, Mahnstufe, Freitext. Seit 01.09.2026 mit Menüpunkt „Rechnungen" ganz oben in der Admin-Leiste (vor „Artikel"). Die Route /admin/invoices gab es längst — sie stand in keiner Menüleiste, erreichbar war die Liste nur über den Kunden oder Finanzen. Sichtbar über FeatureService.zeigtFaktura() (Faktura-Lizenz ODER Fail-open bei Demo/frischer Instanz); nicht isModuleLicensed('factura') — das ist im Code gesperrt
Entwurf verlassen, PDF+XML unveränderbar ablegen, Mail in die Versandqueue stellen (Retry/Backoff via EmailOutboxWorker); Wiederversand offener Rechnungen per allowNonDraft. Je Kunde steuert InvoiceDeliveryFormat, ob die Mail PDF, XML oder beide Anhänge trägt; die GoBD-Ablage bleibt vollständig. „Nur XML" ohne erzeugbare E-Rechnung bricht mit INVOICE_XML_NOT_AVAILABLE ab statt eine Mail ohne Rechnung einzureihen
Zwei Wege, die Weiche steht in DocumentPdfService und wird JE BELEGART getrennt gestellt: hat der Mandant eine eigene .xls im Anhang template hinterlegt (Rechnung/Gutschrift ⇒ invoice.xls, Angebot/Proforma ⇒ offer.xls, Lieferschein ⇒ delivery.xls), druckt weiter FlexCel mit unverändertem Belegbild — sonst das gebaute Layout aus den DocumentLayoutSettings des Mandanten (QuestPDF). Wer nur offer.xls hochgeladen hat, druckt sein Angebot aus Excel und seine Rechnung im neuen Layout; das ist Absicht (nimmt niemandem ein selbst eingestelltes Belegbild weg) und betrifft laut Messung vom 14.08.2026 über 369 Produktions-Mandantendatenbanken genau EINEN Mandanten, einen Testmandanten. Kassenbeleg, SEPA-Mandat und Bewirtungsbeleg gehen IMMER an FlexCel. Der Lizenzserver bleibt am BrandedInvoicePdfService (Gate Invoice:UseBrandedTemplate), Android ebenfalls bei FlexCel — dort ist QuestPDF gar nicht kompiliert (EXCLUDE_DESKTOP_DEPS)
Gepflegter Bankname je Bankkonto (Finanzen → Bankkonten, Feld „Institut") und zur Fallback-Bankverbindung (Einstellungen → Finanzen → E-Rechnung). Rangfolge im PDF: gepflegtes Institut → Ableitung aus der IBAN (BLZ-Datenbank via IIbanValidator) → freies Feld BankAccount.Name. Die Maske schlägt das Institut beim Eintragen der IBAN vor, überschreibt eine Eingabe aber nie. Für die E-Rechnung ist der Institutsname unerheblich — EN 16931 kennt zu BT-84/BT-86 keinen; das XML bleibt unverändert (es führt weiterhin BankAccount.Name)
Was ein Mandant ohne eigene .xls am Belegbild einstellen kann: Logo (Upload, Position, Größe), Akzentfarbe, Layout-Variante, Tabellenspalten (Pos-Nr., Einzelpreis, Steuersatz, Artikelnummer, Einheit) und eigene Texte je Belegart (Rechnung/Angebot/Lieferschein) inkl. Zahlungsblock. Schrift nur aus geschlossener Liste, kein Kunden-Upload — eine nicht einbettbare Schrift zerstört die PDF/A-3-Konformität und damit die E-Rechnung, nicht bloß die Optik. Der Beleg trägt im Kopf den Aussteller, nicht die DiKAS-Wortmarke (platformDocument: false) — hier stellt ein Mandant seinem Kunden eine Rechnung
Zahlteil + Empfangsschein (210×105 mm, SIX IG 2.3) als eigene letzte Seite des Rechnungs-PDFs — Schalter DocumentLayoutSettings.Payment.SwissQrBill (Maske „Belegdarstellung", Vorgabe AUS; der CH-Demo-Seed schaltet ihn ein — Nachzug CH-2). Wirkt nur bei Instanzwährung CHF/EUR, echter Rechnung (keine Gutschrift/Angebot/Lieferschein, keine Lastschrift) und Bankverbindung. Pairing: BankAccount.QrIban gesetzt ⇒ QR-Referenz QRR (27 Ziffern, Modulo 10 rekursiv), sonst IBAN + SCOR (ISO 11649 „RF…"); die Referenz wird beim Ausstellen in CustomerInvoice.PaymentReference gespeichert (SwissPaymentReferenceAssigner in CreateInvoice/SendInvoice/AboInvoiceRun; nur bei QR-IBAN oder CHF-Instanz) und deterministisch aus Kunden-+Rechnungsnummer abgeleitet — Bestandsbelege ohne Wert bekommen beim Druck dieselbe. Nur S-Adressen: Aussteller aus SystemLicenseData (Street darf die Hausnummer tragen, Country als ISO-Code Pflicht), Zahlungspflichtiger aus Billing-Schnappschuss/Kundenstamm — fehlt ihm ein Pflichtfeld, entfällt er (erlaubt). QRBill.Validate läuft vor dem Zeichnen; rot ⇒ Rechnung ohne Zahlteil + Log-Warnung, nie kein Beleg. Lib Codecrete.SwissQRBill.Core 3.5.0 (MIT)
Strukturiertes XML nach EN 16931, eingebettet ins PDF und einzeln abrufbar
Erkennt Belege aus der Altsystem-Übernahme, deren Positionen nicht zum Kopf-Netto passen, und rechnet die Positionen neu; Kopfsummen bleiben unangetastet. Vorschau ist Standard, geschrieben wird nur mit apply: true. Abos werden mitrepariert.
Zwei Fälle, beide Vorschau ohne apply=true: (1) unbrauchbare Nummer (Platzhalter „neu", Leerstring, Whitespace) ⇒ Beleg zurück auf Entwurf, damit er löschbar ist und beim erneuten Ausstellen eine frische Nummer zieht; (2) Dublette (seit 06.09.2026, Befund 47) ⇒ der älteste Beleg einer Nummer behält sie, jeder jüngere bekommt die nächste freie Nummer derselben Serie + Journaleintrag INVOICE_NUMBER_REISSUE. Automatisch nur, was das Haus nicht verlassen hat (kein Archiv-PDF, kein Mailversand, keine Mahnung/Erinnerung, keine Zahlung, keine SEPA-Einreichung) — alles andere wird nur gemeldet und gehört storniert.
Reiner Lese-Report: welche bereits gebuchten Zahlungszuordnungen hätte die heutige, verschärfte Regel nicht vorgenommen — je Befund mit IBAN-Inhaber und passenden offenen Rechnungen. Schreibt nichts
Zeigt Betreff und Text der Rechnungsmail vor dem Versand
Voll- oder Teilzahlung erfassen, Skonto, Überzahlung (landet als Kundenguthaben), Status fortschreiben. Recht invoices.finalize (seit 07.09.2026, wie beim Gegenteil „Bankzuordnung lösen"); die vier serverseitigen Absender (Onboarding-Kartenzahlung, Echtzeit-Überweisungsbestätigung) laufen dafür in einem SystemContext
Reiter „Zahlungseingang" listet die Bankzuordnungen aus dem Zahlungsjournal und löst sie einzeln; die Rechnung fällt auf offen/teilbezahlt/überfällig zurück, PaidDate geht mit weg, die Mahnstufe bleibt stehen. Braucht invoices.finalize. Der Unmatch löst die Buchung als GANZES — bei einer Sammelzahlung nennt die Meldung die mitbetroffenen Rechnungen. Von Hand erfasste Zahlungen (ohne Journalbezug) sind so NICHT rückholbar
Listet die zur Rechnung gebuchten Zahlungs- und Gutschriftsbuchungen
Bestehende Rechnung zwischen Lastschrift und Überweisung umstellen; Lastschrift braucht eine IBAN am Kunden (IBAN_REQUIRED), ein bereits eingereichter Einzug ist gesperrt
Schreibt den Einzugsstatus einer Lastschrift-Rechnung fort (z. B. Rücksetzen nach verworfener SEPA-Datei — sonst wird nie wieder eingezogen)
Unbezahlte Rechnungen gruppiert, Standard-Gruppierung nach Mahnstufe
Rechnung stornieren; erzeugt eine steuercharakter- und gesamtrabattgetreue Gutschrift aus dem Rechnungs-Nummernkreis (GS-RE-022713)
Gutschrift mit Betrag und Grund gegen eine Rechnung ausstellen, ohne sie zu stornieren. Recht invoices.finalize (dasselbe wie Storno, seit 07.09.2026) und eine Zeile INVOICE_CREDIT_NOTE im GoBD-Änderungsjournal. 🪤 In der Oberfläche gibt es dafür keinen Knopf — nur den Storno-Weg; InvoiceService.createCreditNote ist ein Klient ohne Aufrufer. Genau EIN serverseitiger Absender, und der bringt seine eigene Erlaubnis mit: der Reklamations-Entscheid (ResolveClaimCommand, Etappe W6) prüft stock.claim und schickt den Command in SystemContext.Enter("reklamation-erstattung") — sonst verlöre das Lagerpersonal den Erstattungsentscheid (Welle 24)
Mehrere offene Rechnungen in einem Zug als bezahlt schließen
Offene Posten eines Kunden per Gutschrift abschreiben
Bestehende Rechnung als neuen Entwurf kopieren
Dieselben Positionen ohne Preise; kein eigener Belegtyp
Seit 07.09.2026 kennen die drei PDF-Dienste eine vierte Art: die Lieferantenbestellung (DocumentKind.PurchaseOrder, PurchaseOrderTemplate.xls, eigene Label in DE und ES). 🪤 Sie ist die einzige, bei der wir nicht der Absender, sondern der BESTELLER sind — der Adressblock trägt „LIEFERANT", die Kundennummer ist UNSERE bei ihm. Preisspalten bleiben, Bankblock und Zahlungsziel fallen weg. Fachlich geführt im Lagerbereich (07)
Mehrzeiliger Freitext unter der Position, auch im ZUGFeRD (BT-127). Seit 01.09.2026 beim Hinzufügen eines Artikels aus dem Stamm vorbelegt: Artikel.Remark („Bemerkung"), ersatzweise Artikel.Description („Beschreibung") — Regel an EINER Stelle (editor-positions.ts, artikelLangtext()), genutzt von Rechnungs-, Angebots- und (seit 03.09.2026) Abo-Editor. Nur beim Hinzufügen; danach ist der Text Inhalt der Position, eine spätere Artikeländerung schreibt keine bestehende Rechnung um. Max. 2000 Zeichen — seit 03.09.2026 auch am Abo geprüft
Eigenes Feld unter dem Artikelnamen im Abo-Reiter „Positionen". Der AboInvoiceRun kopiert ihn in jede erzeugte Rechnung, damit steht er auf PDF und E-Rechnung. Bei der Artikelauswahl wird die Bemerkung des Artikels übernommen; ein selbst getippter Text bleibt stehen, ein übernommener wird beim Wechsel des Artikels ausgetauscht
Anlegen, versenden, annehmen, ablehnen; eigener Nummernkreis und eigene Vorlage
Wandelt das Angebot über den normalen Rechnungsweg in eine Rechnung
Druckt aus offer.xls; ?proforma=true schaltet auf „Proforma-Rechnung" um
Kunde bekommt nach Plan regelmässig eine Rechnung
Mehrzeilige, optionale Notiz je Abo. Beim Lauf wird sie mit dem Periodendatum aufgelöst und als unveränderlicher Rechnungstext gespeichert: {periode}, {periode:MM.yyyy}, Monat-/Jahrversatz wie {periode-1M:MMMM yyyy} bzw. {periode+1M:MM.yyyy} und {periode-1J:yyyy}. PDF und ZUGFeRD/XRechnung tragen denselben Text (BT-22); das Leistungsdatum im XML bleibt unabhängig das Periodendatum (BT-72).
Zeile aufklappen zeigt, WAS abgerechnet wird: Positionen (inkl. Langtext und Kennzeichnung einmaliger Posten), Netto/Steuer/Brutto, abgerechneter Zeitraum und Empfängeradresse. Spalte 1 ist Firma/Kunde (Klick öffnet den Kunden), der Zeilenklick klappt auf
Verschickt eine bereits finalisierte Rechnung nochmal per Mail (offen, teilbezahlt, überfällig). Ändert am Beleg NICHTS — die Mail trägt die byte-identische Ablage aus dem GoBD-Archiv
Fällige Abos berechnen — Vorschau und echter Lauf, gegen Parallellauf gesperrt (Lock mit Heartbeat); pro Abo+Periode dedupliziert; Lastschrift-Kunden ohne Mandat bekommen eines automatisch. Erzeugt nur Rechnungen — der Versand läuft separat über den BankTransfer des Laufs. Bei einem schon bezahlten Monats-Erstabonnement bleibt die Folgeabrechnung am Monatsersten, liegt aber mindestens einen vollen Monat nach dem Start (31.08. → 01.10., nicht 01.09.). Drei Abos überspringt der Lauf vollständig, ohne NextInvoiceDate vorzurücken: Reseller-abgerechnete (ResellerBilledPartnerId), Händler-Kunden in Einrichtung (ResellerSetupPending) und Lizenzen in der kostenlosen Testphase (IsTrial, seit 2026-08-08). Die Vorschau spiegelt alle drei
Monatspause mit Wiederaufnahme, Kündigung zum Periodenende
Feld „Nächste Rechnung" in der Abo-Maske (nur beim Ändern). Zurückdatieren ist erlaubt, zeigt aber vorher unter dem Feld UND im Bestätigungsdialog, wie viele Rechnungen über welchen Betrag der nächste Lauf daraus erzeugt. Weiter als 24 Monate zurück lehnt der Server ab (der Lauf überspränge das Abo ohnehin). „Startdatum" ist beim Ändern nur noch lesend — es dokumentiert den Vertragsbeginn und speist den Termin nur bei der Anlage
Hängt ein Abo an einen anderen Kunden (Dublettenauflösung nach der Altsystem-Übernahme); bereits erstellte Rechnungen wandern NICHT mit
Mahnstufen 1–3 mit eigener Mail-Vorlage je Stufe; Simulation und Mahnlauf; Mails über die Versandqueue. Karenzfrist zwischen zwei Stufen (BackendConfig.DunningMinIntervalDays, Vorgabe 14 Tage) — seit 06.09.2026 in der Mahnwesen-Maske einstellbar (0–365 Tage, 0 = keine Karenz); bis dahin stand das Feld in keinem HTTP-Vertrag und war nur direkt in der Datenbank zu setzen und Riegel gegen fragwürdige Zahlungszuordnungen, überstimmbar per ignoriereZuordnungsWarnung
Rechnungen mit SepaDebitStatus 1 (eingereicht) oder 4 (Datei erzeugt, wartet auf Bestätigung) lässt der Mahnlauf bewusst aus (Owner-Regel „per SEPA eingereicht wird nie gemahnt“). Die Simulation meldet dafür sepaInFlightCount/sepaInFlightAmount; die Mahnwesen-Maske zeigt seit 07.09.2026 Anzahl UND Betrag im Klartext („x Rechnungen / y € sind per SEPA eingereicht und werden nicht gemahnt“). Ohne diese Zeile sieht die Lücke zwischen offenen Posten und Mahnliste wie ein Fehler des Laufs aus
Jeder Lauf schreibt ein DunningRun-Dokument: wer, wann, welche Rechnungen, an welche Adresse, wer nichts bekommen hat, ob der Riegel übergangen wurde
Zeigt die Mahnmail eines Kunden vor dem Versand
Präfix und Startnummer je Serie (Rechnung, Angebot, Werkstatt, Abo). Der Zähler wird einmalig je Serie an den Rechnungsbestand angeschlossen (Stempel InvoiceSeries.CounterSyncedAt), und jede vergebene Nummer wird vor der Ausgabe gegen den Bestand geprüft ⇒ INVOICE_NUMBER_DUPLICATE statt einer stillen Doppelnummer (Befund 47)
Mandanten-Schalter unter Finanzen → Steuersätze (ganz oben, im Normal-Modus sichtbar): Rechnungen ohne USt (Positionen 0 %), Pflichthinweis auf PDF und im XML (ZUGFeRD-Steuerkategorie E statt Z). Die Entscheidung wird beim Erstellen an der Rechnung gespeichert (CustomerInvoice.IsSmallBusinessExemption) — ein späteres Umschalten ändert Alt-Rechnungen NICHT. Auf ES-Deployments ausgeblendet (deutsches Recht)
Das PDF (Branded/Modern, Simple) trägt die Steuerbezeichnung des Mandanten aus Finanzen → Steuersätze („zzgl. 8,1 % MWST", Spaltenkopf „MWST", Kurzform „MWST:") — InvoicePdfLabels.MitSteuername(TaxRateHelper.ResolveTaxName(...)), eine Kopie des geteilten Label-Sets, ohne Bezeichnung byte-gleich zum Bestand („zzgl. 19 % MwSt."). Der Satz wird nie gerundet (0.##). Die Aussteller-Steuernummer wird nach ihrem Präfix beschriftet: CHE-… ⇒ „MWST-Nr." (auch im FlexCel-Pfad), zwei Buchstaben + Ziffer ⇒ „USt-IdNr.", sonst „Steuernummer"; die Firmenstammdaten-Masken (E-Rechnung, Compliance-Schritt) nennen das CH-Format „CHE-123.456.789 MWST" als Platzhalter.
Erkennt EU-Nicht-DE-USt-IdNr. (in VatId oder TaxId) am amtlichen VIES-Format des jeweiligen Landes (alle 26 EU-Präfixe, seit 04.09.2026 auch ES/NL/IE/CY/FR mit Buchstaben) und Drittland, setzt die Steuer auf 0 und das passende Belegkennzeichen
PDF und XML werden beim Finalisieren einmalig am Rechnungsdokument abgelegt
INVOICE_-Ereignisse in einem eigenen Logstrom mit 10 Jahren Aufbewahrung
Eigene .xls-Vorlage je Belegart hochladen (Rechnung, Angebot, Lieferschein)
Faktura arbeitet immer mit der vollständigen Admin-Oberfläche; der Normal-/Experten-Umschalter wird dort nicht angezeigt. So bleiben DATEV, Vorlagen, Steuer- und E-Rechnungs-Einrichtung ohne versteckte Reiter erreichbar. POS-Mandanten behalten ihren reduzierten Modus.
Texte für Rechnung, Bankeinzug und die drei Mahnstufen
Monatliches Rechnungs-Kontingent, je nach Tarifstufe: Gratis 5 (DE) / 10 (ES), „dikas Faktura Rechnung" (9 €) 100, „dikas Faktura Pro" (19 €) 1.000, darüber auf Anfrage. Gezählt werden nicht gelöschte, nicht stornierende Rechnungen des laufenden Kalendermonats (UTC)
Neuverträge mit DocumentStoragePolicyVersion=1 haben ausschließlich einen Gesamtdeckel: Gratis 0, 60-Tage-Test 1 GiB, bezahlte Tarife 1 GiB, Faktura Pro 5 GiB; Zusatzpakete addieren je 1 GiB. Gezählt wird die gespeicherte Größe aus allen vier Anhang-Quellen (Belege, Ausgaben, Bankanhänge, noch nicht übernommene Auto-Belege); eine Übernahme zählt nicht doppelt. Ersetzungen reservieren nur das positive Byte-Delta, parallele Uploads werden atomar reserviert, Löschen gibt Platz frei. Am Limit bleiben Lesen und Export unverändert; nur neue/vergrößerte Uploads scheitern. Altverträge ohne Policy-Version behalten bytegenau die bisherige Faktura-Monats-/Gesamtlogik beziehungsweise die unbegrenzte POS-Logik
Holt Lieferantenbelege per IMAP und macht daraus Buchungseinträge
Erfassten Eintrag samt Anhängen löschen und den belegten Beleg-Speicher freigeben — „Ignorieren" allein gibt kein Byte frei. Scheitert das Löschen des Eintrags, bleiben die Anhänge unangetastet (kein halber Stand); ein bereits gelöschter Eintrag lässt sich aus einem alten Browser-Tab heraus nicht mehr übernehmen, ändern oder ignorieren (ENTRY_DELETED)
Reißt ein E-Mail-Anhang das Beleg-Kontingent, entsteht der Eintrag trotzdem, aber ohne Belegbild. Der Eintrag merkt sich die Zahl der fehlenden Anhänge und ist in der Eingangsliste markiert („Belegbild fehlt"). Ein erneuter Abruf ergänzt sie am selben Eintrag — nur am selben Kalendertag: der IMAP-Abruf sucht ab dem letzten Abrufzeitpunkt, wer erst am Folgetag Speicher freigibt, bekommt die Mail nicht mehr. Es wird deshalb nirgends ein automatisches Nachholen versprochen
Alte Route /rest/cashpoint/invoices/{key} für ausgelieferte Clients. bydate nimmt seit 06.09.2026 optional page/pageSize und liefert dann genau eine Seite in derselben Form und Reihenfolge (aufsteigend nach Bonnummer); der Abholer blättert, bis eine Seite kürzer als pageSize ist. Ohne die Parameter antwortet die Route unverändert — Fremdsysteme rufen sie, der Vertrag bleibt
Kein Treffer in diesem Bereich. Gesamte Website durchsuchen
Oft gesucht
Weiterstöbern
Marketing-Cookies erlauben?
Wir würden gerne mit Google Ads messen, welche Anzeigen zu einer Anmeldung führen. Dafür werden Cookies gesetzt und Daten an Google (USA) übertragen — nur mit deiner Einwilligung. Unsere anonyme Reichweitenmessung (Matomo) läuft davon unabhängig. Details und Widerruf in der Datenschutzerklärung.
