Start With the Benefit, Recipient and Responsible Taxpayer

A sales incentive, employee benefit and dealer reward can look similar in a catalog while following different tax and operating paths. Before selecting a mechanism, record who grants the benefit, who receives it, why it is granted, whether it is additional to an agreed payment or salary, what the recipient can obtain and when control passes to that recipient.

That first classification determines which questions must be sent to payroll, finance and qualified advisers. It also determines which data the loyalty platform needs. Employee benefits require an employment-related view. Rewards for dealers, customers or independent sales partners require a separate third-party view. Mixed programs should not merge these populations into one undifferentiated tax bucket.

The program brief should state that the final assessment belongs to the granting company and its qualified tax and legal advisers. The loyalty operator can implement agreed rules and prepare records, but it should not silently choose a legal treatment from a marketing label. That distinction protects both the participant experience and the audit trail.

What § 37b EStG Actually Provides

Section 37b EStG is an elective flat-rate income-tax mechanism for specified non-cash benefits. The statute permits a taxpayer to apply a 30% flat income-tax rate to qualifying benefits that are not cash. The assessment base is generally the taxpayer’s expenditure including VAT. Additional charges such as the solidarity surcharge and, where applicable, church tax need separate treatment.

For benefits to third parties, the provision addresses operationally motivated additional benefits and certain gifts. It can also apply to qualifying additional non-cash benefits for the taxpayer’s own employees, subject to statutory exclusions. The official wording excludes flat-rate treatment where expenditure per recipient and financial year exceeds €10,000 and where expenditure for a single benefit exceeds €10,000. The administrative guidance distinguishes the annual maximum amount from the single-benefit ceiling, so systems should not treat both tests as the same field.

The election is applied uniformly within the relevant scope; employees and non-employees are treated as separate recipient groups in the administrative guidance. A company therefore needs a documented election decision, population definition and period—not ad hoc selection of convenient individual rewards. Under Section 37b(3), a benefit taxed through this mechanism is left out when the recipient’s income is determined, and the granting taxpayer must inform the recipient that the tax was assumed.

Primary source: Section 37b EStG and the Federal Ministry of Finance guidance reproduced in the 2026 Wage Tax Handbook.

Use the €50 Employee Threshold as a Monthly Control

Section 8(2), sentence 11 EStG is a monthly threshold for qualifying benefits in kind, not a transferable annual allowance. Benefits valued under Section 8(2), sentence 1 remain unrecognized for income-tax purposes when the aggregate advantage after participant payments does not exceed €50 in the calendar month. If the threshold is exceeded, teams should not assume that only the excess is affected.

Vouchers and money cards qualify only when they are treated as benefits in kind under Section 8(1), sentence 3 and are granted in addition to salary already owed. The statutory and administrative tests cover what can be purchased, the permitted acceptance network and the exclusion of cash-like functionality. A label such as “gift card,” “wallet” or “points account” is not sufficient.

Timing also matters. The BMF guidance explains that a third-party voucher is generally received when it is handed over and a money card no earlier than when value is loaded; an employer-only voucher can follow a different timing rule. The operating system therefore needs the agreed tax event, not merely the later redemption date. Monthly aggregation, corrections, co-payments and rejected transactions must be designed around that event.

Primary source: Section 8 EStG and the BMF guidance on vouchers and money cards.

Compare the Operating Paths Before Choosing One

The decision is not simply “tax-free or flat-rate.” Each route requires its own eligibility test, data, accounting handover and participant message. The overview below is a project-planning aid; it is not a substitute for a case-specific assessment.

The comparison should also address social-security treatment, VAT, deductibility, wage-tax timing and industry-specific compliance where relevant. Those questions are related but are not answered merely by selecting Section 37b or the €50 threshold.

Design the Participant-Level Data Record

A defensible process connects every reward event to the approved rule that governed it. At minimum, define the program, granting entity, recipient identifier, recipient group, benefit category, description, valuation method, gross expenditure where relevant, tax event date, financial year and correction status. Do not infer missing tax fields later from campaign names.

The record should distinguish issued, canceled, returned and replaced benefits. It should preserve the original event and a linked correction rather than overwriting history without explanation. For a monthly employee threshold, aggregation must follow the agreed event date and include other relevant benefits supplied outside the loyalty platform where the employer’s assessment requires them. For Section 37b, the process should support both the annual recipient total and the single-benefit test.

Exports need a named recipient system and owner. Payroll, financial accounting and adviser workpapers may require different identifiers, cut-off dates and formats. Reconciliation should compare platform events, procurement or travel invoices, fulfillment status and the accepted downstream file. A dashboard alone is not evidence that the recipient-level handover is complete.

Retention, access, correction and deletion rules should be agreed for the specific architecture. Tax documentation requirements, data-protection requirements and the loyalty program’s participant-facing retention promises must be reconciled rather than applied in isolation.

Separate Dealers and Business Partners From Employees

B2B incentive recipients are third parties, even when the campaign experience resembles an employee rewards program. A manufacturer may reward dealers, installers, resellers or independent sales partners across several distribution levels. The granting entity, commercial reason, recipient identity and recipient’s relationship to the sponsor must remain explicit.

Section 37b can be relevant to qualifying benefits for non-employees, but the benefit must first be taxable for the recipient under the applicable rules. The BMF guidance reflects Federal Fiscal Court decisions that restrict the provision to taxable benefits. Teams should therefore avoid the shortcut “all dealer rewards are covered.” The assessment may also need to consider whether a benefit is additional to an agreed service or consideration.

Business-expense deductibility for gifts is a separate question. The current wording of Section 4(5), sentence 1, number 1 EStG uses a €50 annual threshold for gifts to persons who are not employees of the taxpayer. That rule should not be confused with either the €50 monthly employee threshold or the €10,000 figures in Section 37b. Internal anti-bribery, procurement and industry rules may add further approval requirements.

For multi-level programs, document which company grants each benefit, who reports it and how duplicate participant identities are prevented. If a wholesaler and manufacturer both fund rewards, funding and tax responsibility should be modeled as separate facts rather than flattened into a single sponsor field.

Define PRODATA’s Role Without Transferring Tax Responsibility

PRODATA can translate an approved tax and accounting concept into program rules, data fields, controls and agreed exports. The project can combine loyalty design, individual software work, integration, program operations and reward fulfillment. This is useful when participant experience and downstream documentation must follow the same source events.

The exact service scope is agreed per project. It may include recipient-group mapping, value and event capture, threshold or plausibility checks defined by the client, exception workflows, reporting and interfaces for payroll or financial accounting. These are operational and technical services. PRODATA does not replace the granting company’s tax adviser, make binding tax classifications for the client or guarantee that a program structure produces a particular tax outcome.

The implementation brief should identify who supplies the approved rule set, who maintains rates and limits, who releases changes, who handles exceptions and who files or pays tax. It should also state which fields PRODATA generates, which come from the client or another supplier and which system is authoritative after export.

For related operating topics, see loyalty managed services, employee incentive programs, reseller programs and the PRODATA company profile.

Build Release Controls Before the First Reward

A tax workflow is ready only when rules, interfaces, exceptions and communication have been tested together. Use a small set of representative scenarios: an employee benefit below the monthly threshold, an aggregate that reaches or exceeds it, a third-party reward, a cancellation, a replacement, a co-payment, a year-end boundary and an event near a Section 37b limit.

For each scenario, verify the source event, classification code, value, timestamp, recipient group, aggregation, exception status, export and reconciliation result. Confirm that changes to a program rule are versioned with an effective date. A silent overwrite can make past reports impossible to reproduce.

Test participant communication as carefully as accounting output. The message should identify the granting company, describe the benefit and state any required tax-assumption notice without promising an outcome outside the approved scope. Customer service needs a route for questions it cannot answer and should not improvise tax advice.

Set a launch decision with named signatories from the relevant client functions. The go-live record should reference the approved adviser position, configured rules, test evidence, export acceptance and fallback. If a critical field or decision is missing, the safe fallback is to hold the affected reward event for review.

Evaluate Providers on Evidence, Interfaces and Responsibility Boundaries

A provider comparison should begin with one agreed scenario and one common responsibility matrix. Ask each bidder to show where recipient group, granting entity, benefit value, event date, annual total, monthly aggregate and correction history are stored. Require a demonstration of the exception workflow and the exact export received by payroll or finance.

Separate current product capability, configuration, project-specific development, client responsibility and third-party dependency. A generic statement that software “supports § 37b” does not prove that the proposed workflow matches your benefit types, election decision, systems or control owners.

Commercial comparison should include discovery, rule configuration, data migration, integration, testing, reporting, ongoing changes, exception handling and client effort. References should match the claimed role: ask who made the tax decision, what the provider implemented, which output was reconciled and how rule changes were governed.

Request an exit path as well. Participant-level event data, rule versions, correction links and export history should remain available in an agreed format and period. The proposal should state what can be exported, by whom, at what cadence and how final reconciliation is completed.

What a Reviewable Tax-Workflow Brief Contains

Record the granting entity, recipient populations, benefit types, purpose, approved legal basis or treatment, valuation method, tax event, aggregation period, thresholds, exclusions, election scope, notification wording, payroll and finance interfaces, correction process, retention rule and responsible approvers.

Attach representative test cases and expected results. Label every item as confirmed, client-supplied, adviser-approved, technically demonstrated or still open. The brief should make it possible for a reviewer to trace a reward from program rule through issue or redemption event to the accepted accounting handover.

Revalidate the workflow when the benefit catalog, voucher product, recipient population, granting entity, funding model, system interface or law changes. A previously accepted configuration should not be assumed to cover a materially different campaign.