Framework agreements in German B2B: what a Rahmenvertrag settles

A Rahmenvertrag is a German framework agreement: it fixes the terms of a relationship for a defined period, and every later order draws on them instead of reopening the negotiation. What usually surprises a cross-border seller is not the structure but the range of things a German buyer wants settled before the first delivery: payment periods, early-payment discount, order units, invoicing rhythm and document format. This article covers what such an agreement usually contains, where German law narrows your freedom to agree, and what your platform has to carry.

What a Rahmenvertrag is, and what German law does not say about it

The most important point comes first and is counterintuitive: in private commerce, German law does not define a framework agreement. There is no provision stating what a Rahmenvertrag must contain or how it differs from an ordinary sales contract. Which means the agreement is worth exactly what has been written into it.

The only place a statute defines a framework agreement

A definition does exist, but in public procurement law. § 103(5) GWB describes a Rahmenvereinbarung as an agreement between one or more contracting authorities and one or more undertakings that sets the conditions for contracts to be awarded during a given period, „in particular with regard to price”. That is a serviceable working definition for private deals too, as long as you remember where it comes from.

The implementing regulation goes further. § 21 VgV caps the term of a framework agreement in public procurement at four years, unless a special case justified by the subject matter applies, and sets out in detail how individual contracts are awarded under it. None of those limits bind a private agreement, but the split between framework terms and individual orders is identical.

Agreement or order: the practical difference

A framework agreement is usually not an order and does not on its own oblige the buyer to take a specific delivery unless that has been written in. The delivery is triggered by a call-off order, in German an Abruf. Hence a split that many systems handle badly:

• The agreement says: which products, at what prices, over what period, against what committed volume and on what payment terms.
• The order says: how many units, by when and to which delivery address, referencing the agreement as the basis for its price.
• A counter joins the two: how much of the committed volume has been called off and how much is left before the term ends.

Billing models that follow from the agreement

A framework agreement settles more than price. It also settles how you get paid, and that is the most underrated part of the negotiation, because the gap between an invoice per delivery and one collective invoice per month translates directly into manual work in your finance team.

Billing models a framework agreement can set. Which one applies is a matter of the contract, not of German law.

These models combine, and that is where disputes start. An annual rebate calculated on turnover that already included volume discounts needs an explicit clause stating the base it is calculated from. How to structure the pricing rules themselves is a separate topic, covered in our piece on B2B pricing models and framework agreements.

Payment terms: what the law fixes and what you negotiate

This is where freedom of contract stops. The German civil code limits how long a buyer may take to pay, and it puts a price on being late. Worth knowing before you negotiate, because the buyer usually knows it.

• Beyond 60 days only expressly: § 271a(1) BGB provides that an agreement under which the creditor may demand payment only more than 60 days after receiving the counter-performance is effective only if it was expressly agreed and is not grossly unfair to the creditor.
• Public buyers are held tighter: where the debtor is a public contracting authority, § 271a(2) BGB makes a period over 60 days ineffective, and a period over 30 days requires objective justification.
• Inspection periods are capped too: § 271a(3) BGB treats a review or acceptance period longer than 30 days the same way: express agreement, and not grossly unfair.
• Default arrives on its own: under § 286(3) BGB the debtor of a payment claim is in default at the latest if payment is not made within 30 days of the claim falling due and an invoice or equivalent payment statement being received.
• Being late has a statutory price: § 288(2) BGB sets default interest at nine percentage points above the base rate for payment claims where no consumer is involved, and § 288(5) BGB adds a flat 40 euro claim.

Skonto: a discount that has to survive the invoice and the ERP

Skonto is a percentage discount for early payment, normally written as a payment condition, for example „2 percent discount if paid within 10 days, net 30”. The rate and the window are always contractual: German law does not prescribe either.

That does not make it purely commercial, though. § 14(4) UStG lists among the mandatory invoice contents the consideration broken down by tax rate, together with any reduction of the consideration agreed in advance, unless it is already reflected in the amount. The Skonto condition therefore has to be visible on the invoice, not only in the framework agreement.

Operationally, Skonto hurts somewhere else. The buyer deducts it themselves, transferring less than the invoice total, and your system has to recognise that payment as settled in full rather than short. Without that, your finance team gets a monthly list of supposed arrears that are in fact correct payments with the discount taken.

Invoices and documents: the easiest place to trip

§ 14(4) UStG lists the mandatory contents of an invoice: the full names and addresses of both parties, the tax number or VAT identification number of the issuer, the issue date, a sequential invoice number, the quantity and type of goods or scope of the service, the delivery or performance date, the consideration broken down by tax rate, and the applicable rate and tax amount or a reference to an exemption.

E-invoicing and who the obligation actually binds

§ 14 UStG defines an electronic invoice as one issued, transmitted and received in a structured electronic format that allows electronic processing. A PDF attached to an email does not meet that condition. The obligation to issue such an invoice applies where both parties to the transaction are established in Germany.

Transitional rules sit in § 27(38) UStG. In short: for turnover carried out after 31 December 2024 and before 1 January 2027, a paper invoice or another electronic format with the recipient consent is still allowed, and in defined cases, among them issuers with prior-year turnover up to 800 000 euro and data exchanged via EDI, the transition runs to the end of 2027.

Two consequences for a seller outside Germany. First, the transitional rules cover issuing, not receiving, so German companies have to be able to accept a structured invoice earlier than they have to send one. Second, the obligation follows establishment rather than VAT registration, so a seller without an establishment in Germany is not directly caught by it. Confirm your own status with a tax adviser, because it depends on how you are present in that market.

A separate layer is documents required not by statute but by the buyer: their own purchase order number (Bestellnummer), the framework agreement number, the delivery note number, sometimes a delivery location code. If the buyer requires them and the invoice lacks them, it goes into clarification and the payment clock starts again. The rest of the entry obligations for this market sit in our German market checklist, which is written for consumer sales.

What the platform has to carry

Translated into system requirements. The list below is not a set of features to buy, it is the set of things that have to be recorded, counted and visible somewhere, whether that is the ERP or the platform.

• The contract as an object, not as a price: an agreement with start and end dates, a product scope, a buying entity and delivery locations, with prices attached to it rather than the other way round.
• A volume counter: committed against called off, visible to the sales team and to the customer in their account.
• Orders that reference the agreement: every call-off points to the contract it takes its price from, so counter and invoice agree.
• Payment terms per customer and per contract: the period, the Skonto with its own window, the credit limit. An attribute of the relationship, not a global store setting.
• Periodic invoicing: collecting deliveries from a period onto one invoice while keeping the link to the delivery notes.
• Versioning of terms: an amendment creates a new version with an effective date, while the previous one stays readable for invoices already issued.
• Buyer reference fields: the customer purchase order number and agreement number carried from the order through to the delivery note and the invoice.
• A structured output format: an invoice as a file built for machine processing, not only a PDF built for printing.
• The ERP as source of truth: prices, limits and stock in the system finance works in, with an explicit direction of synchronisation.

We are not repeating the price resolution hierarchy here, because it has its own article: individual price before group, group before volume tier, tier before promotion. That is covered in B2B pricing models and framework agreements, and wiring it into the accounting system is what we do under B2B store with ERP integration. The broader context sits in our guide to B2B eCommerce.

Where an off-the-shelf SaaS usually needs a workaround

This is our assessment based on how these systems are architected, not the result of a feature-by-feature test of named platforms. Treat it as a list of questions to put to a vendor before signing, not as a verdict on any particular tool.

• A volume commitment spread across many orders: most pricing engines resolve a price within a single basket, not against a declaration made for the year.
• Retrospective rebates: a bonus calculated after the period closes is an accounting operation rather than a basket discount, so it usually ends up outside the system.
• Collective invoicing per period: the „one order, one payment, one invoice” model is the SaaS default and is hard to bend.
• Versioned terms with history: changing a price is usually easy; reconstructing which price applied on 15 March, and on what basis, rarely is.
• Skonto and deductions during payment matching: a payment lower than the invoice tends to be read as short rather than as a correct payment with the discount taken.
• Structured invoice output: generating an invoice in a machine-processable format is rarely an out-of-the-box function.

What to settle before the first order

A checklist for the negotiation, ordered by what you will later have to enter into a system:

• Scope and term: which products, which buyer entities, which delivery locations, from when to when, and what happens at expiry.
• Volume and consequences: whether the declaration is a commitment, what happens on a shortfall, and whether the price is corrected if it occurs.
• Billing model: invoice per delivery or collective, in what rhythm, and on what base any rebate is calculated.
• Payment terms: the period, the Skonto with its own window, the credit limit, and the event that starts the clock.
• Documents: which reference numbers must appear on the invoice and in which format the buyer wants to receive it.
• Changing the terms: how an amendment is made and from when it applies to orders already placed.

At Seedlight we start these projects with a Blueprint, a review of the agreements, prices, invoicing process and what your ERP actually exposes, before anyone writes code. The heaviest work usually turns up in settlement rather than in the storefront. The scope and commercial model are described on our pricing page, and the modules themselves are B2B pricing and quotes and the B2B ordering portal, where a regular buyer orders against their contract without calling sales. If you are still deciding whether wholesale belongs online at all, start with B2B eCommerce.

Sources

• § 103(5) GWB, definition of a Rahmenvereinbarung in public procurement law: gesetze-im-internet.de/gwb/__103.html (accessed 17 August 2026).
• § 21 VgV, term of a framework agreement and award of individual contracts: gesetze-im-internet.de/vgv_2016/__21.html (accessed 17 August 2026).
• § 271a BGB, agreements on payment, inspection and acceptance periods: gesetze-im-internet.de/bgb/__271a.html (accessed 17 August 2026).
• § 286 BGB, default of the debtor: gesetze-im-internet.de/bgb/__286.html (accessed 17 August 2026).
• § 288 BGB, default interest and the flat compensation: gesetze-im-internet.de/bgb/__288.html (accessed 17 August 2026).
• § 14 UStG, electronic invoices and mandatory invoice contents: gesetze-im-internet.de/ustg_1980/__14.html (accessed 17 August 2026).
• § 27 UStG, transitional rules for electronic invoicing: gesetze-im-internet.de/ustg_1980/__27.html (accessed 17 August 2026).