---
id: ADR-MBR-STR-005
title: Share Accounting Identity for Membership Offerings
product_area: membership
module: structure
revision: 1
status: proposed
design_intent: confirmed
source_sha:
  services-membership: 5994c270e8a37a30f848e99ba5b5ee6b87c08893
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
decision: >-
  Packages and local dues offerings are Membership extensions keyed by their Accounting product identity, with
  shared product fields read from Accounting.
constrains:
  - DOM-MBR-STR-004
  - DOM-MBR-STR-002
  - SVC-MBR-STR-configuration
  - SVC-MBR-STR-structure
  - WF-MBR-STR-004
origin: >-
  D-1 (Andrew, 2026-10-18: the package is the product): services-membership:docs/migrations/packages-as-
  products/README.md#What a package is now
alternatives:
  - option: Maintain an independently named package pointing to an arbitrary product.
    why_not: >-
      Separate descriptions and activity could drift for what staff regard as one offering; the recorded
      product decision replaces this model.
  - option: Transfer the entire product catalogue record to Membership.
    why_not: >-
      That would move shared pricing and Accounting responsibilities across their established service
      boundary.
consequences:
  - Accounting and Membership reference the same offering identity and Accounting status.
  - Package and dues reads obtain shared product fields through one port.
  - >-
    Product references are soft and validated on extension creation; later package updates do not repeat that
    validation.
supersedes: []
evidence:
  - >-
    services-membership at 5994c270: modules/structure/ports/accounting-products.ts;
    modules/configuration/db/membership-packages.table.ts; modules/structure/db/organizational-unit-dues-
    products.table.ts
---

# Share Accounting Identity for Membership Offerings

## Context

The former package model stored its own name and activity alongside a separate product. The recorded change establishes one shared product identity with a Membership extension.

## Decision

This record documents the existing product decision. Membership owns membership-specific configuration, while Accounting retains the product and its shared fields.

## Alternatives Considered

Maintain an independently named package pointing to an arbitrary product. Separate descriptions and activity could drift for what staff regard as one offering; the recorded product decision replaces this model. Transfer the entire product catalogue record to Membership. That would move shared pricing and Accounting responsibilities across their established service boundary.

## Consequences

Accounting and Membership reference the same offering identity and Accounting status. Package and dues reads obtain shared product fields through one port. Product references are soft and validated on extension creation; later package updates do not repeat that validation.