Contract

In Zenskar, a contract is the central digital schema that represents a commercial agreement between a service provider and a customer. It serves as the single source of truth for the system, defining the parameters for generating invoices and calculating recognized revenue.

A contract ensures consistency across financial operations by centralizing:

• What is being sold (products and features)
• The pricing and billing cadence
• The rules for revenue recognition
• Audit trails for financial compliance

---

Data architecture

A contract is structured as a hierarchy. This design allows Zenskar to handle everything from simple flat-rate subscriptions to complex, multi-year enterprise agreements with varying terms.

Phases

A phase is a time-based segment within a contract. It defines specific commercial terms for a set duration, and a contract must contain at least one. Because customer relationships often change over time, phases allow you to model those transitions within a single contract rather than creating separate agreements. Common examples include:

• Trial periods: A phase with a fixed duration (e.g., 14 days) where products are priced at zero.
• Step-up pricing: An initial phase with discounted rates followed by a phase at standard pricing.
• Contract amendments: A new phase capturing updated pricing or product composition mid-term.

Products and features

Each phase acts as a container for the items being sold:

• Products: The core units of value, such as subscriptions, usage-based services, or one-time fees. These define the primary pricing models.
• Features: Specific commercial modifiers or configuration settings, such as tax rules (e.g., Avalara) or volume discounts, that enhance or modify the behavior of products within the phase.

---

Parallel workflows

Zenskar operates every contract through two distinct, concurrent workflows. This design supports organizations at various stages of financial maturity.

Background execution

The revenue recognition workflow runs automatically for all contracts. Early-stage organizations or those using simple cash accounting may not require this output immediately, but the data remains available to support future audits or transitions to accrual-based accounting without requiring system reconfiguration.

stateDiagram-v2
    [*] --> ContractCreated
    ContractCreated: Contract created
        ContractCreated --> BillingWorkflow : Billing terms defined
        ContractCreated --> RevenueWorkflow : Performance obligations identified
    BillingWorkflow: Billing workflow
    RevenueWorkflow: Revenue workflow
    %% Billing Workflow
    state BillingWorkflow {
        [*] --> BillingScheduled
        BillingScheduled --> InvoiceGeneratedAndSent : Invoice created and sent to customer
        InvoiceGeneratedAndSent --> PaymentPending : Awaiting payment
        PaymentPending --> PaymentReceived : Payment received
        PaymentReceived --> ReceiptIssued : Receipt issued
        ReceiptIssued --> [*]
        BillingScheduled: Billing scheduled
        InvoiceGeneratedAndSent: Invoice generated and sent
        PaymentPending: Payment pending
        PaymentReceived: Payment received
        ReceiptIssued: Receipt issued
    }
    %% Revenue Recognition Workflow
    state RevenueWorkflow {
        [*] --> RevenuePlanCreated
        RevenuePlanCreated --> RevenueScheduleGenerated : Revenue schedule created
        RevenueScheduleGenerated --> RevenueRecognized : Revenue recognized on fulfillment of performance obligations
        RevenueRecognized --> [*]
        RevenuePlanCreated: Revenue plan created
        RevenueScheduleGenerated: Revenue schedule generated
        RevenueRecognized: Revenue recognized
    }
    note right of ContractCreated
      Contract includes product, price, billing, and revenue terms.
    end note
    note right of RevenueRecognized
      Recognized revenue is recorded against the revenue schedule and reflected in deferred revenue reports.
    end note
    note right of ReceiptIssued
      Receipt confirms payment and closes the billing transaction.
    end note

---

The revenue recognition framework

For businesses subject to ASC 606 or IFRS 15 standards, Zenskar automates the technical execution of the five-step revenue recognition model.

System boundaries

Zenskar manages the automated transformation of contract data into financial reports, but does not replace professional legal or accounting judgment regarding the validity of an agreement.

1. Identify the contract: (Out of scope) The user must determine if a legally enforceable agreement exists.
2. Identify performance obligations: Zenskar identifies distinct obligations based on the products and features configured within each phase.
3. Determine transaction price: The system calculates total consideration, accounting for fixed and variable components.
4. Allocate price: Zenskar allocates the transaction price across performance obligations.
5. Recognize revenue: Revenue is recognized as obligations are satisfied, based on the schedules defined in the contract.

🚧

Important: Zenskar manages the commercial structure and financial logic of a contract but does not assess its legal enforceability.

---

Contract ingestion methods

To support various quote-to-cash (Q2C) pipelines, Zenskar provides three methods for instantiating contracts. Each suits a different operational context.

• Automated sync: Direct ingestion from external systems such as CRM (e.g., Salesforce), CPQ, or ERP platforms. Best suited for organizations with existing commercial tooling that should remain the system of record.
• Manual configuration: Creation via the Zenskar administrative interface for physical or non-standardized agreements that fall outside automated pipelines.
• Programmatic creation: Use of Zenskar APIs to instantiate contracts directly from custom application logic. Best suited for organizations building proprietary Q2C workflows or requiring fine-grained control over contract structure.

stateDiagram-v2
    [*] --> Contract_Options
    Contract_Options: Contract ingestion method
    Contract_Options --> Sync_Existing_Contracts : Option 1 — Automated sync
    Contract_Options --> Create_New_Contracts_Manually : Option 2 — Manual configuration
    Contract_Options --> Create_New_Contracts_API : Option 3 — API creation
    Sync_Existing_Contracts: Automated sync
    Create_New_Contracts_Manually: Manual configuration
    Create_New_Contracts_API: API creation
    Sync_Existing_Contracts --> Contracts_Available
    Create_New_Contracts_Manually --> Contracts_Available
    Create_New_Contracts_API --> Contracts_Available
    Contracts_Available: Contracts available in Zenskar
    Contracts_Available --> [*]

    state Sync_Existing_Contracts {
        [*] --> Sync_In_Progress
        Sync_In_Progress --> Sync_Completed : Sync successful
        Sync_Completed --> [*]
        Sync_In_Progress: Connecting to third-party system (ERP, CRM, or CPQ)
        Sync_Completed: Contract data ingested and validated
    }

    state Create_New_Contracts_Manually {
        [*] --> Contract_Creation
        Contract_Creation --> Contract_Ready : Contract saved
        Contract_Ready --> [*]
        Contract_Creation: Configuring contract in Zenskar UI
        Contract_Ready: Contract reviewed and confirmed
    }

    state Create_New_Contracts_API {
        [*] --> Contract_Creation_API
        Contract_Creation_API --> Contract_Ready_API : API call successful
        Contract_Ready_API --> [*]
        Contract_Creation_API: Contract payload submitted via API
        Contract_Ready_API: Contract instantiated and validated
    }

    note left of Contract_Options
        Sync contracts from a third-party system (ERP, CRM, or CPQ),
        configure them manually in the Zenskar UI,
        or instantiate them programmatically via the Zenskar API.
    end note

---

Next steps:

• To learn how to create your first contract in the interface, see the [Getting started: your first contract] guide.
• For a detailed list of contract fields and data types, see the [Contract API reference].