One payment, one place
Whether from reconciliation, the payment run or recorded by hand — there is one payment on the invoice, never a second truth.
The statement comes in as CAMT, MT940 or CSV. Document number in the reference, amount, discount, name — the rules find the invoice and say how sure they are. You confirm with one click, or accept all certain ones at once. Suppliers are paid in the payment run; the DATEV export serves your accountant.
A transaction is the bank's statement: it is hashed, de-duplicated and never edited. The rules propose — document number, amount, discount, name, bulk payment — and a person confirms. A confirmed match writes the payment onto the invoice; "paid" exists exactly once in the system. What has no document stays visibly open instead of quietly vanishing.
The payment run freezes creditor and amount on creation, is released once — with four eyes when your profile requires it — and produces a pain.001 that is validated against the schema before it is stored. The return flow on the statement closes it via the same rules. The DATEV export stamps every row it takes: a period goes to your accountant exactly once.
Whether from reconciliation, the payment run or recorded by hand — there is one payment on the invoice, never a second truth.
Supplier invoices are checked against the order, go into the payment run and are closed by the statement.
"Which invoices are more than 30 days overdue?" — Bob answers from the same data. Matching and transferring stays a matter of confirmation.
Yes. The DATEV export produces the posting batch in DATEV format for invoices, credit notes, payments and incoming invoices of a period. Every row is stamped; a second export of the same period contains only what is new.
CAMT.053 (XML), MT940 and CSV with a column profile per bank. Duplicate transactions are recognised by hash and skipped.
No-obligation introductory call. We build a live app with you that mirrors your real workflow.