Invoicing and Payment Schedules¶

Overview¶

Note

The scheduling of invoices is controlled by the Payment Plan Plugin. See Legacy Invoice Scheduling below for details on how Socotra works if the payment plan plugin is not implemented.

The payment schedule name is set on new policies on creation, either in the UI or when calling the Create Policy endpoint by including the paymentScheduleName in the PolicyCreateRequest4. If not included, the payment schedule will use the default, as described below.

The payment schedule name (along with other data) is provided to the payment plan plugin which then determines how to interpret and implement the schedule.

Manual Schedule Changes¶

Along with the ability to control the behavior of a payment plan, the payment plan plugin can change an existing policy’s payment schedule from one schedule to another. This affects only future invoices; already-generated invoices will not be affected. To change a policy’s payment schedule, use the following endpoint:

Change Payment Schedule¶

POST /policy/{policyLocator}/paymentSchedule

Request:
Name
Position
Type
Required
paymentScheduleChangeRequest
body
PaymentScheduleChangeRequest
required
policyLocator
path
string
required
Response:void

PaymentScheduleChangeRequest¶

{
  // Required
  newPaymentScheduleName : string
}

Note

The new payment plan will be persisted on the policy, and future transactions will be invoiced with the new plan.

Note

Manually changing the payment plan requires use of the payment plan plugin.

Payments¶

A payment object marks an invoice as paid and stores data about the payment. Data fields may be configured on payments, except the Group and Lookup field types.

Note

Socotra does not support partial payment or cash allocation.

Configuration¶

Payment schedules and terms are defined in policy/policy.json. The contents of invoices are generated automatically. The data to be stored on payments is defined in /payment/payment.json.

Policy Configuration¶

Add defaultPaymentTerms and paymentSchedules to policy.json, as follows.

Both paymentSchedules and defaultPaymentTerms must be in the configuration.

Each configured payment schedule option will be available in a dropdown when creating a policy in the Socotra UI.

The first payment schedule in the list will be the default.

defaultPaymentTerms determines how long before the due date the system will issue the invoice.
{
  "fields": [ ],
  "documents": [ ],
  "defaultPaymentTerms": {
    "amount": 7,
    "unit": "day"
  },
  "paymentSchedules": [
    {
      "type": "total",
      "name": "upfront",
      "displayName": "Up Front"
    },
    {
      "type": "monthly",
      "name": "monthly",
      "displayName": "Monthly"
    },
    ,
    {
      "type": "every_two_weeks",
      "name": "every_two_weeks",
      "displayName": "Biweekly"
    }
  ]
}

Payment Configuration¶

The file payment.json contains payment configuration. The only configuration for payments is what fields should be saved on them. For the available data types, see Fields. The Group and Lookup field types are not available on payments.

{
  "fields": [
    {
      "name": "payment_ref",
      "title": "Payment reference number",
      "type": "string"
    }
  ]
}

Invoice Templates¶

When Socotra issues an invoice, it renders the document template policy/invoice.template.liquid. This template has access to the same data available to other Document Templates, as well as data.invoice_financials:

data.invoice_financials: {
    "total_due": BigDecimal,
    "total_due_currency": String
    "gross_premium": BigDecimal,
    "gross_premium_currency": String,
    "gross_taxes": BigDecimal,
    "gross_taxes_currency": String
    "gross_fees": BigDecimal,
    "gross_fees_currency": String,
    "fees": [
        {
            "name": String,
            "display_name": String,
            "amount": BigDecimal,
            "amount_currency": String,
            "description": String
        }
    ],
    "tax_groups": [
        {
            "name": String,
            "display_name": String,
            "amount": BigDecimal,
            "amount_currency": String
        }
    ],
    "financial_transactions": [
        {
            "amount": BigDecimal,
            "amount_currency": String,
            "posted_timestamp": long,
            "policy_modification_locator": String,
            "policy_modification_name": String,
            "type": "premium" | "tax" | "fee",
            "peril_locator": String,
            "peril_name": String,
            "peril_display_name": String,
            "tax_locator": String,
            "tax_name": String,
            "tax_display_name": String,
            "fee_locator": String,
            "fee_name": String,
            "fee_display_name": String
        }
    ]
}

Invoice Rendering¶

For policy issuance, the first invoice may be rendered either when the governing quote is accepted or the policy is issued. This is controlled with the generatingEvent property in policy.json. See the quotes documentation for details.

For endorsements, renewals, cancellations, and reinstatements, invoices are rendered when the associated transaction reaches accepted state.

For premium reports, invoices are rendered when the premium report is issued.

Legacy Invoice Scheduling¶

Invoices are normally scheduled with the Payment Plan Plugin. If the plugin is not implemented, Socotra will fall back to legacy behavior as desribed here.

Socotra supports the following payment schedules:

total
monthly
annually
semiannually
quarterly
every_two_weeks
every_week

Billing Periods¶

Billing periods start on the start date of the policy, and stay on the same date of each month (except for the week-based schedules). Invoices become due at the start of the billing period.

The first invoice is issued immediately, and subsequent invoices are issued before the due date according the configured payment terms. Endorsements, cancellations, and withdrawal trigger also immediate invoice issuance.

Invoices¶

Installments have equal amounts where possible, except for partial periods at the end of the term. Charges are split equally among billing periods, with straight-line, to-the-millisecond proration for partial periods. See also Premium allocation documentation.

Rounding errors are collected on the last invoice for a period of coverage. If the policy duration is not a whole number of months (for example, a policy that runs 2020-01-01 to 2020-06-17), the last billing period will be for less coverage and therefore be for less than the other invoices.

Fees are split evenly across invoices the same manner as premiums.

Backdated Policy Invoicing¶

When creating a policy with an effective date in the past, multiple invoices may be generated. For example, a monthly invoiced policy created with an effective date three months ago will have four invoices created instead of just one.

Note

When multiple invoices are to be created, only the first will be guaranteed to be generated synchronously in the finalize or issue request. Others will be generated after a few minutes.

Name	Position	Type	Required
paymentScheduleChangeRequest	body	PaymentScheduleChangeRequest	required
policyLocator	path	string	required