ERPNext v16 developer: German invoicing back end (ZUGFeRD/XRechnung, DATEV, EBICS, API)

We are MS Dach GmbH, a German roofing service company (25 staff, ~4000 outgoing invoices per year). We are replacing our legacy software and use ERPNext v16 on Frappe Cloud ONLY as the financial back end for outgoing invoices. Our own app (Supabase/React) controls ERPNext via REST API. You set up ERPNext and build one small custom app (no core changes). TIMELINE: the whole project must be finished within 1-3 months. You need at least 30 hours per week for this project. SCOPE (9 milestones, see full briefing below): - M1 Base setup: SKR03, German taxes incl. reverse charge (§13b), number series, payment terms, roles, custom fields - German print formats (invoice, down-payment/final invoice, credit note, dunning letters) - E-invoicing with eu_einvoice (ZUGFeRD + XRechnung, KoSIT-valid) - Custom app: down-payment and final invoices (deduct received payments, BT-113) - REST API endpoints + webhooks for our app - Banking (EBICS) + payment reconciliation rules - Dunning run, DATEV export, GoBD settings - Migration of open items + go-live support MUST HAVE: - Proven ERPNext ACCOUNTING experience (please link projects) - Frappe custom app development without core changes - REST API / webhooks, Git workflow, good written English - Strong plus: erpnext_germany, eu_einvoice, erpnext_datev HOW WE WORK: detailed briefing with acceptance criteria and test cases, FIXED PRICE PER MILESTONE, next milestone only after acceptance, all code in our GitHub repo, all accounts owned by us. Shortlisted candidates do a short paid trial task (6-8 h). IN YOUR PROPOSAL, PLEASE SEND: 1. Fixed price and duration for EACH milestone M1-M9 2. Links to similar ERPNext accounting/localisation work 3. Will you do the work personally or someone from your team? 4. Hours per week available for us (incl. your work outside Upwork) and earliest start date 5. Your experience with erpnext_germany / eu_einvoice / DATEV Proposals without fixed prices per milestone will not be considered. ===================================================== FULL BRIEFING ===================================================== 1. Who we are MS Dach GmbH is a German roofing service company (gutter cleaning, roof cleaning, roof coating, repairs, maintenance), ~25 employees, ~4000 outgoing invoices per year: - ~400 down-payment invoices + ~300 final invoices per year - ~1500 invoices to property managers / homeowner associations (WEG), companies and public authorities - ~250 credit notes and corrections per year - a few reverse-charge invoices (§13b UStG) to construction companies ERPNext is used only as the financial back end for outgoing invoices. Customers, jobs, routes and the office UI are built in our own system (Supabase + React). 2. Architecture (fixed – do not change) - Customers, properties, bill-to parties, projects, quotes, jobs, routes, work reports, customer history → our app (Supabase/React) - Office UI: review & release invoices, trigger corrections, release dunning proposals, match unclear payments → our app - Sending all e-mails/letters → our app (n8n) - Document numbers, taxes, PDF + ZUGFeRD/XRechnung, posting, bank import & reconciliation, receivables, dunning run & dunning documents, DATEV export, period closing → ERPNext - Purchase invoices → not in scope Rules: 1. Office staff never work in ERPNext. ERPNext is driven via REST API + webhooks. 2. No customers, quotes or jobs are created in ERPNext. Customers (bill-to parties) and items are copies from Supabase (key = Supabase ID). 3. ERPNext never sends e-mails. 4. No changes to ERPNext/Frappe core. All custom work lives in one custom app msdach_erp in our GitHub repo. 5. All accounts (Frappe Cloud, GitHub, banking) belong to MS Dach. You get personal user access. 6. Every change goes to the TEST site first, then LIVE. 3. Environment - ERPNext v16 on Frappe Cloud (small plan), two sites: test + live - Apps: erpnext_germany, eu_einvoice, erpnext_datev, banking (ALYF, EBICS with HypoVereinsbank) - Integration partner on our side: n8n (built by our team, not you). You deliver the ERPNext endpoints/webhooks and their documentation. 4. Business rules you must implement 4.1 Accounting - Chart of accounts SKR03, accrual-based VAT (Soll-Versteuerung), fiscal year = calendar year - SKR03 revenue, §13b revenue, dunning-fee and cash-discount accounts as defined with our tax office (list provided in M1). No advance-payment accounts (see 4.4) - DATEV export: private/one-off customers map to a collective debtor account (name in posting text); business customers map to fixed 5-digit debtor numbers. Internally every bill-to party is its own Customer (needed for receivables and dunning) with a field "DATEV account". - Tax templates: 19 %, 7 %, 0 % reverse charge §13b (mandatory note, VAT ID required, code AE), tax-exempt with reason. Default per bill-to party, overridable per invoice. - All rates, fees, deadlines, cash discounts and payment terms must be configurable by our team leads without a developer, with a "valid from" date. 4.2 Bill-to party (= ERPNext Customer, copy from Supabase) supabase_id (unique), name (free text), c/o line (property manager), billing address, invoice e-mail, type (private / WEG / owner / company / authority), customer group, VAT ID, Leitweg-ID, our supplier number at the customer, payment terms, dunning-fee override, e-invoice format, DATEV account, dunning block. 4.3 Items (= ERPNext Item, copy from Supabase) Service code, description, unit, tax rate, revenue account, labour share % for §35a EStG (e.g. gutter cleaning 100 %, roof coating 80 %, window 35 %, editable per line). 4.4 Document types - Invoice: from a job in Supabase; with or without title grouping - Fixed-price invoice: lines without unit prices, only totals - Small-amount invoice ≤ 250 €: simplified, PDF only - Down-payment / partial invoice: from the payment plan in Supabase; posted like a normal invoice (normal revenue account, VAT shown) - Final invoice: shows full service; deducts payments actually received on down-payment invoices, each listed with number, date, net, VAT; result = amount due. Unpaid down-payment invoices are automatically closed when the final invoice is posted (not open, not dunned). E-invoice with prepaid amount BT-113. No double deduction. - Credit note (partial): e.g. discount −40.00 € gross; references original invoice; own number series - Credit note (full = cancellation): cancels the original completely; then a new invoice with a new number is created (pre-filled) - Invoice correction: references original, changed lines (wrong quantity/price) - Delivery note: available, not used Every credit note/correction stores a mandatory reason (sent from Supabase). 4.5 Mandatory invoice content (validated before posting) All items of §14(4) UStG incl. service date and service address if different from billing address; §13b note; labour-share sentence on private and WEG invoices; retention note on private invoices (§14b UStG). No signatures. 4.6 Customer references (generic list per invoice) Type + value, mapped to e-invoice fields: Leitweg-ID → BT-10 (mandatory for authorities – only hard check) · Purchase order / SAP no. / customer's order no. → BT-13 · Contract no. → BT-12 · Property / unit no. → BT-18 · Cost centre → BT-19 · Other → BT-22 note. All references also printed in the PDF header. 4.7 E-invoicing Format chosen automatically: private → PDF · WEG/owner/property manager/company → ZUGFeRD (European standard profile) · authority → XRechnung · ≤ 250 € → PDF. All document types (incl. down-payment, final, credit note, correction) must validate with the KoSIT validator. A visual PDF for every XRechnung. No e-delivery network, no attachments in the e-invoice. 4.8 Bank & payments - ALYF Banking, EBICS, daily automatic import (HypoVereinsbank) - Matching: invoice number in remittance text → amount → name; never amount only - Partial payments (allocation order fees → interest → principal, §367 BGB), overpayments/credit, cash discount within terms, one bulk payment split over several invoices - Residual amounts under 5 € written off automatically - Unclear transactions are matched in our app and posted via API - Target ≥ 80 % correct automatic matches, 0 wrong matches 4.9 Dunning - 3 levels: reminder · 2nd notice · 3rd notice; each 7 calendar days from sending (fixed date) - Fees per level (default 0 / 5 / 10 €, override per customer), late interest from level 2, day-exact from due date, days/360, rate with "valid from" - Daily run creates proposals only; our app releases them via API; then posting + PDF - Dunning block per invoice and per customer - Dunning letter layout: letterhead, table (invoice no., date, due, amount, interest from level 2), totals, payment deadline, level text, copy of invoice attached. Texts provided by us. 4.10 Accounting compliance (GoBD) Posted documents are immutable; corrections only by counter-document; full audit log; monthly period closing; DATEV EXTF export (few columns, defined with our tax office) with lock flag + all invoice PDFs of the month; 10-year retention. Provide the technical part of our GoBD process documentation. 4.11 Print formats (German) Invoice with/without titles · fixed price · down-payment · partial · final (with deduction table) · credit note · correction · small amount · delivery note · reminder · 2nd · 3rd notice. Layout follows our current documents and letterhead (provided as PDF). Page x of y. EPC QR code for bank transfer. 4.12 Number series Continue our current series (invoice, credit note, dunning) from the legacy system's last number; new series creatable by team leads. 5. API / webhooks you deliver (in msdach_erp) A1 Upsert customer (bill-to party) by supabase_id A2 Upsert item by service code A3 Create / update / discard draft invoice of any type (idempotent by request ID; structured validation errors) A4 Get preview PDF + XML of a draft A5 Submit (post) draft → returns number, final PDF, XML A6 Create credit note / correction / cancellation with reason A7 Set / clear dunning block (invoice, customer) A8 Get dunning proposals; post a released dunning; get dunning PDF A9 Get open items per customer / per job A10 Get unmatched bank transactions with suggested invoices A11 Match / split / unmatch a payment (until period close; log user + time) A12 Write off residual under 5 € W1–W4 Webhooks: invoice posted · payment matched (amount, date, open rest, status) · overdue / dunning level changed · credit note/correction posted Webhooks signed, with retry and logging. OpenAPI documentation in the repo. Target: draft + preview under 5 s, posting under 3 s. Exact payload fields will be frozen together with our Supabase developer before milestone M5. 6. Emergency mode - If our app or n8n is down: team leads can create an invoice directly in ERPNext (flag "emergency"). - If ERPNext is down: dunning run pauses; invoices wait. - Daily backup with download to our storage; restore test on a separate server once per quarter. - Short operations guide in the repo (restart, restore, emergency mode). 7. Data migration Only open items at cut-over date + running down-payment projects with received payments. Nothing else is migrated. Open-items total must match exactly (0 € difference). 8. Out of scope Quotes, jobs, routes, customer master maintenance, work reports, e-mail sending, purchase invoices, stock, payroll, CRM, subscriptions, legacy invoice history, any core modification. 9. Milestones (fixed price per milestone, next one only after acceptance) M1 Base setup: sites, apps, company, SKR03, taxes, number series, customer groups, payment terms, roles, custom fields, settings with valid-from → Acceptance: checklist + demo on test site M2 Print formats (all 12) → each format with sample data approved by us M3 E-invoicing + customer references → KoSIT green for every document type and format M4 Down-payment / final invoice app → test cases T1–T3 exact to the cent M5 API + webhooks (A1–A12, W1–W4) + OpenAPI doc → Postman/n8n test of every endpoint M6 Bank (ALYF Banking) + reconciliation rules → 1 month real statements on test: ≥ 80 % auto, 0 wrong M7 Dunning → test case T10 exact; proposals → release → posting works M8 DATEV export + GoBD (period close, audit, technical process doc) → test import accepted by our tax office M9 Migration of open items + go-live support → open-items total 0 € difference Max. 2 milestones in parallel. 10. Test cases (anonymised real data) T1 Final invoice, total 6882.96 €; down-payment 1 paid 2189.60; down-payment 2 paid 1408.96 → amount due 3284.40 T2 Final invoice, total 11615.00; paid 3079.72 + 3915.70 → amount due 4619.58 T3 Final invoice, total 11445.90; down-payment 1 paid 2879.80; down-payment 2 (4246.40) unpaid → amount due 8566.10; down-payment 2 closed automatically, not dunned T4 Partial credit note (discount) → −40.00 gross / −33.61 net, references original T5 Correction → −380.80 gross T6 Fixed-price invoice → 134.95 without unit prices T7 Small invoice 225.01 → PDF only T8 Invoice to authority → XRechnung, KoSIT green, Leitweg-ID in BT-10 T9 §13b invoice → 0 %, mandatory note, §13b revenue account T10 2nd notice → open 1080.32 + interest + fee 5.00 = total (interest per configured rate) T11 One bulk payment for 3 invoices → split correctly T12 Residual 3.20 € → written off automatically 11. Collaboration rules - Work only in our repo, small pull requests, each with description and test result - Weekly short written status (done / next / blockers) - No access sharing, no work outside the agreed scope without written approval - Code, configuration and documentation belong to MS Dach 12. Documents you receive (per milestone) Proposal: this briefing · M1: access to test site + repo, customer groups, payment terms, number-series end values, tax note texts · M2: letterhead PDFs, sample PDFs of all current documents, German texts · M3: 2–3 real e-invoice requirements of public customers · M4: 3 real down-payment/final cases (anonymised) · M5: interface contract (exact JSON payloads) · M6: EBICS access for the test site, 1 month of real bank statements · M7: dunning rules sheet · M8: DATEV column set from our tax office · M9: open-items list at cut-over date