New Ideas 💡

In Planning

Next Up (Approved)

In Progress

Done

Available

Pelcro Roadmap

<h3>Problem Statement</h3>Currently, the accounting dashboard does not provide a yearly revenue export, limiting our ability to generate annual financial summaries directly from the platform. Additionally, existing accounting reports do not include the Company Name field, which makes it difficult to track and analyze spend on a per-company basis. This gap impacts financial reporting efficiency and prevents accurate spend attribution at the company level. Feedback: We would like to have a yearly revenue export available through the accounting dashboard. We would also like Company Name to be listed in existing accounting reports from the accounting dashboard so we can track spend per company.

Backlog

Accounting

Deferred & Recognized Revenue Report

An Anonymous User

Problem Statement Metadata is used across many of Pelcro's customers to create different workflows such as opt-ins for privacy policy &amp; terms &amp; conditions, determining access levels for end-users, across integrations &amp; JS customizations. Since metadata fields &amp; values are case sensitive, the current way of adding metadata makes a lot of room for human error. We need to offer a smarter way for admins to create customers from the platform and their metadata Adding a metadata field should be selectable from a dropdown menu containing all metadata fields existing on the site/account in question We should also have the option to create a new custom metadata field name Indicating the value of a field should be selectable from a dropdown menu containing all metadata values for this exact field existing on the site/account in question

Ability to add metadata via dropdown

Helena Okoroegbe

Notes are not currently shared. While the Pelcro Dashboard has a place for them, it is unused, and we do not have access to the note history for customers.

Product Board

User/Growth Ideas

Customer service notes

🔍 Problem Statement Currently, Pelcro does not allow subscription changes between plans that include shipments. This limitation forces manual intervention and increases workload for customer service teams, while also preventing subscribers from managing their own plans.<div data-type="horizontalRule"><hr></div>💡 User Story As a Pelcro admin, I want the platform and website to support plan changes for shipment-based subscriptions so that customer service doesn’t need to manually cancel and recreate subscriptions.<div data-type="horizontalRule"><hr></div>🎯 Definition of Done (DoD) A feature is done when:✔️ The Core API and UI allow subscription changes between shipment-based plans. ✔️ All validations are consistent with existing plan change rules (e.g., billing cycle alignment, proration if applicable). ✔️ End users can perform plan changes directly through the UI without requiring customer service intervention.

Enable subscription changes for shipment-based plans

Rana Haleem

🔍 Problem Statement As a business, I have no way of calculating proration in advance of making a subscription update through the Pelcro API, which results in uncertainty about charges and prevents me from displaying accurate costs to my customers before they commit to the change. 💡 User Story As a Pelcro API user, I want an endpoint that calculates proration for a subscription change in advance, so that I can show customers a clear summary of the charges or credits they will incur before confirming the update. 🎯 Definition of Done (DoD) ✔ Given I want to preview the impact of a subscription update, when I call the new proration calculation API with the subscription ID and intended changes, then I should receive a response with a detailed breakdown of:<ul><li>Upcoming invoice amount (including proration).</li><li>Credits applied, if any.</li><li>Net change due. ✔ The endpoint should not persist changes—it should only return a calculation. ✔ Documentation is updated with request/response schema and usage examples. ✔ SDKs and Postman collection updated to include the new endpoint.</li></ul>

Add Proration Calculation Preview API for Subscription Updates

Changing subscription prices is complex. Past issues include automation bugs where scheduled phases were not respected. The Core API’s batch update limitations forced reliance on Stripe API instead.

Price change complications

<h3>Problem Statement</h3>Currently, multiple user logins under a single subscription are only supported when the subscription is of type membership or has an assigned seat license. Feedback: Allow multiple user logins under a single subscription without requiring a membership or seat license.

Discovery Board

Multiple logins per subscription

What would you like to be able to do? (One idea per form): As an admin, I would like to be able to delete saved credit cards from accounts at any time, even if they are the only card saved and even if the card is linked to an active subscription. How would that help you?: We have customers that want to cancel autopayments or change their payment method to "send invoice" and currently we can't make that change without starting a new subscription. It would be incredibly helpful to have the ability to delete saved cards so renewals can't be automatically charged in cases like this. By deleting the card, there will be nothing to pull the payment from which ideally would then lead to the customer receiving an email invoice or notification that payment has not been processed for their autorenewal. Also, I believe we should have the ability to delete saved card info at any time when it is requested by a customer. If they no longer want saved card information on file, we should be able to delete that even if there is no new card info to replace it. I think this should be a feature for admin only, not on the customer side. How important is this to you?: CriticalEmail address: <a href="mailto:ksouders@wtwhmedia.com">ksouders@wtwhmedia.com</a>——————————————— This task was submitted through Suggest an idea - Product Roadmap <a href="https://form.asana.com/?k=qsv6hMm2wL8SXD_R-h-N9Q&amp;d=742417627358732" rel="noopener noreferrer" target="_blank">https://form.asana.com/?k=qsv6hMm2wL8SXD_R-h-N9Q&amp;d=742417627358732</a>

As an admin, I would like to be able to delete saved credit cards from accounts at any time, even if they are the only card saved and even if the card is linked to an active subscription.

During a call with the Pelcro team we noticed you can “trace an invoice”.&nbsp; We only have the actions of “view subscription and view invoice”.&nbsp;&nbsp;Is it possible for us to also have access to “trace invoice”. Currently we are using a link we add to the accounting dashboard and its cumbersome.&nbsp; It would be very beneficial to be able to just choose trace invoice and be taken directly to the dashboard view.

Ability to Trace accounting activity on an invoice.

Kristyn Chrouch

<h4>Problem Statement</h4>The new activity log on the subscription level does not indicate who performed the action, which reduces auditability and operational clarity for admin users.For example:<ul><li>Subscription created</li><li>Payment taken</li><li>Subscription updated</li></ul>The log shows the action and metadata, but not the user (admin) who performed it.<h4>Requested Adjustment</h4>Enhance activity log entries on the subscription level to include the user who actioned the event.

Add “Actioned By” to activity log on the subscription level

Sara Habib

Planned

New Import Tool

Abdallah Shapsough

Problem: Current list exports do not include price and currency fields, forcing clients to manually reconcile financial data across multiple reports. This increases operational effort and risk of reporting errors.User Story: As a finance or operations user, I want price and currency included in exports so I can generate accurate revenue reports without manual data merging.Definition of Done (DoD):<ul><li>Add <code>price</code> and <code>currency</code> fields to list exports.</li><li>Ensure UI exports include the new columns at the end of export.</li></ul>

Add price and currency to list exports

Problem StatementAdmins currently lack a clear way to apply credit notes directly to invoices, making it difficult to properly adjust invoice balances after an invoice has been created.User StoryAs an admin, I want to be able to apply a credit note directly to an existing invoice, So that I can accurately adjust the invoice balance after it has been created.

Apply Credit Notes to Existing Invoices

<h2>Problem Statement</h2>Pelcro clients (subscription and membership businesses like NYT) need a single, fast dashboard to quickly confirm their business is healthy on a daily basis.Today, revenue, payments, churn, and subscriber activity are spread across reports, making it hard to answer a simple question:“Is my business running smoothly today, or is something broken?”<h2>User Story</h2>As a Pelcro client and business owner,I want to log in daily and immediately see key business metrics and trends,so I can verify revenue, payments, checkout flow, and subscriber activity are behaving normally without deep investigation or alerts.<h2>Feature Summary</h2>A read-only Daily Operations Dashboard designed for quick daily check-ins, focused on:<ol><li>Business momentum</li><li>Payment and checkout health</li><li>Subscriber activity</li><li>Trend comparison vs recent historical baselines (e.g. same time last week)</li></ol>The dashboard is visual, graph-driven, and confidence-oriented (not alert-based).<h2>Core Metrics (All with graphical trends + “same time last week” reference)</h2><ol><li>Revenue (MTD) – line/area graph</li><li>Payments (MTD) – successful vs failed</li><li>Churn (MTD) – count (and rate if available)</li><li>New Subscribers (Last 5 Days) – daily trend graph</li><li>Recent New Subscribers – latest sign-ups list</li><li>Most Active Collaborators – ranked activity list</li><li>Operational Health Indicators (Passive)</li><li>Checkout activity present</li><li>Failed payments within normal range</li><li>No fraud signals detected (if available)</li></ol><h2>API Requirements (High-Level)</h2><ol><li>Aggregated, cached analytics endpoints for:</li><li>Revenue, payments, churn, subscriber counts</li><li>Support time-based comparisons (e.g. same time last week)</li><li>Read-only, fast, and multi-tenant safe</li></ol><h2>Definition of Done (DoD)</h2><ol><li>Dashboard loads quickly and is accessible from Pelcro admin</li><li>All metrics are graph-based with historical comparisons</li><li>Data matches existing Pelcro billing and reporting data</li><li>No alerts or actions triggered from this dashboard</li><li>APIs are documented, tested, and reusable across clients</li><li>Display online vs offline payments top segmentation idea </li><li>Display breakdown of the top products/plans subscribed to </li></ol>

Daily Business Health Dashboard

<h2>Problem Statement</h2>Newspaper publishers want subscribers to add recurring tips for delivery drivers as part of their subscription. Pelcro currently lacks a way to collect these tips, exclude them from revenue, and convert them into accounts payable for carriers or drivers.<h2>User Story</h2>As a subscriber, I want to add an optional recurring carrier tip so my driver is rewarded automatically.As a publisher, I want tips to be billed clearly, excluded from revenue, and converted into AP bills payable to vendors.<h2>Scope &amp; Impact</h2>Impacted Components: UI, API, Accounting &amp; ReportingUse Case: Print subscriptions only<h2>Functional Requirements</h2>Tip Entry<ol><li>Subscribers can add or manage a recurring carrier tip during checkout or via subscription management.</li><li>Tip is optional, fixed-amount, and billed on the same cycle and payment method as the subscription.</li><li>Admins can enable/disable tips and configure allowed amounts. </li></ol>Billing &amp; Invoicing<ol><li>Tips appear as a separate invoice line item (<code>vendor_tip</code>).</li><li>Clearly labeled, non-discountable, non-taxable by default.</li><li>Charged together with the subscription.</li></ol>Accounting Treatment<ol><li>Tips are not revenue and are excluded from MRR/ARR.</li><li>Recorded as liabilities until paid.</li></ol>AP Conversion (Bills &amp; Vendors)<ol><li>Each subscription is linked to a Vendor (individual driver or carrier company).</li><li>On successful invoice payment:</li><li>Pelcro creates AP Bill for the Vendor.</li><li>Tip is added as a Bill Line Item referencing the source invoice.</li></ol>Payouts<ol><li>Pelcro does not execute payouts.</li><li>Publishers pay vendors via existing AP workflows and mark bills as paid in Pelcro.</li></ol><h2>Definition of Done</h2><ol><li>Subscribers can add/manage recurring carrier tips.</li><li>Tips bill correctly and appear separately on invoices.</li><li>Tips are excluded from revenue metrics.</li><li>AP Bills are automatically generated per Vendor.</li><li>Invoice → Bill traceability is available.</li><li>APIs, docs, and automated tests are updated.</li></ol>

Introduce Carrier tips

🧩 Problem StatementThe current subscription create page does not align with modern UI/UX standards. 💡 User StoryAs a platform user,I want a modernized creation subscription page with a clean, consistent, and intuitive layout,so that I can quickly manage data without confusion or unnecessary steps.🎯 Definition of Done (DoD)<h2>- Modernize subscription create page with the latest UI/UX standards.</h2>

Upgrade Subscription create view

<h2>🔍 Problem Statement</h2>As a subscriber purchasing a subscription across multiple sites under the same account, I experience access being limited to only the site where the subscription was purchased, despite the product being configured for availability on multiple sites.&nbsp;This results in confusing access behavior, fragmented content availability, and reduced perceived subscription value, often leading to support requests or duplicate subscriptions.<h2>💡 User Story</h2>As a subscriber of a multi-site product, I want my subscription to grant access across all sites associated with that product, so that I can consume content seamlessly without needing multiple subscriptions.<h2>🎯 Definition of Done (DoD)</h2>A feature is done when:&nbsp;✔️Given a product configured to be available on multiple sites under the same Pelcro account, when a subscriber purchases a subscription using any pricing plan under that product on any site, then the subscriber is granted paywall access on all sites associated with that product.<ol><li>Acc multiple sites &gt; if subscription attached to product, return all subscriptions related to that site.</li></ol>&nbsp;✔️ This change will impact API and SDK/ JS part, specifically:<ol><li>Subscription entitlement resolution at the API level</li><li>Paywall evaluation logic within the Pelcro SDK to recognize cross-site entitlements</li><li>No change to purchase flows or checkout UI behavior</li></ol>&nbsp;✔️ This solution will include the following limitations:<ol><li>Applies only to sites under the same Pelcro account</li><li>Does not extend access across different Pelcro accounts</li><li>Products configured for a single site will continue to behave as they do today</li><li>Retroactive application to existing subscriptions is out of scope.</li></ol>

Subscription across multiple sites

<h2>✨ Feature Request: Enforce 15-Character Minimum for Strong Passwords</h2>Problem StatementWhenStrong password enforcementis enabled, Pelcro currently enforces ahardcoded minimum password length of 8 characters. This does not meet current security standards such asNIST SP 800-63B Rev. 4andOWASP ASVS v5.0, which mandate or strongly recommend aminimum of 15 charactersfor single-factor authentication.&nbsp;<h2>User Story</h2>As a Pelcro site owner or security administrator,I want strong password enforcement to require aminimum of 15 characters,so that new user passwords comply with modern security standards without custom development.&nbsp;<h2>Proposed Change</h2><ol><li>Update the existing Strong password enforcement feature to enforce:</li><li>Minimum password length: 15 characters</li><li>Maximum password length: 64 characters (passphrase support)</li><li>Apply enforcement consistently across:</li><li>Customer sign-up</li><li>Password reset</li><li>Password change flows</li></ol>&nbsp;<h2>Definition of Done (DoD)</h2><ol><li>&nbsp;Strong password enforcement enforces a 15-character minimum for passwords</li><li>Maximum supported password length is 64 characters</li><li>Enforcement applies only to newly created or updated passwords</li><li>Existing passwords are not invalidated or forced to reset</li><li>Validation is enforced at API, UI, and SDK levels</li><li>Clear validation errors are returned when requirements are not met</li><li>Automated tests are updated or added</li><li>Security documentation is updated accordingly</li></ol>

Enforce 15-Character Minimum for Strong Passwords

<h2>Problem</h2>The current signup and onboarding flow contains unnecessary friction and lacks visibility into drop-off points. Users face complexity (password validation, domain requirement, OTP) and unclear next steps once inside the dashboard. This reduces activation rates.We are not currently optimizing for outcome.<h2>User Story</h2>As a business, I want to create my first invoice with the fewest possible steps so I can start billing immediately.<h2>Definition of Done (DoD)</h2><ol><li>Make domain field optional.</li><li>Real-time password validation (inline checkmarks as user types similar to Stripe) </li><li>Remove OTP from signup flow ONLY</li><li>Integrate reCAPTCHA v3 on signup </li></ol>

Reduce Pelcro onboarding sign up friction

<h2>🧩 Problem Statement</h2>Publishers delivering newspapers via internal carriers (vendors — e.g., drivers) assign a vendor to delivery addresses.Currently, Pelcro does not allow flexible segmentation of fulfillments by <code>vendor</code>, nor does the platform-generated fulfillment file clearly structure output by vendor and delivery sequence.This creates manual operational work when coordinating vendor-based deliveries.<h2>👤 User Story</h2>As a publisher operations manager,I want to filter lists and fulfillments by <code>vendor</code>,so that I can generate vendor-specific delivery runs directly from the platform.As a delivery coordinator,I want the generated fulfillment file to include vendor name and be ordered by delivery sequence and vendor,so that operational routing is efficient.<h2>🏗 Proposed Solution</h2>1️⃣ List Builder EnhancementsIn List Builder, allow filtering on:<ol><li><code>vendor</code> (dropdown selector of existing vendors)</li><li><code>vendor</code> = null (unassigned addresses)</li><li><code>vendor</code> ≠ null (any assigned vendor)</li></ol>Filtering applies at the Address object level.2️⃣ Platform Fulfillment File EnhancementWhen generating a fulfillment from the Platform UI:Include Columns:<ol><li><code>vendor_name</code></li><li><code>delivery_sequence_number</code></li></ol><h2>🔌 API Requirements</h2><ol><li>List queries must support filtering by:</li><li><code>vendor_id</code></li><li><code>vendor_id = null</code></li><li>Fulfillment generation must include:</li><li><code>vendor_name</code></li><li><code>delivery_sequence_number</code></li><li>Fields must be exposed in fulfillment response payload</li></ol><h2>✅ Definition of Done (DoD)</h2>✔ List Builder supports filtering by vendor ✔ Can filter for unassigned vendors (null) ✔ Platform-generated fulfillment file includes vendor name ✔ Platform-generated fulfillment file includes delivery sequence number ✔ Fulfillment ordered by sequence ASC, then vendor ASC ✔ API documentation updated ✔ QA validated using:<ol><li>Multiple vendors</li><li>Mixed assigned/unassigned addresses</li><li>Mixed sequence values</li></ol><h2>📊 Business Impact</h2><ol><li>Enables operational vendor segmentation directly in Pelcro</li><li>Reduces manual spreadsheet sorting</li><li>Supports scalable newspaper distribution workflows</li><li>Complements delivery sequence feature</li></ol>

Vendor-Based Fulfillment Segmentation (Platform UI)

<h2>Problem</h2>Pelcro supports recurring invoices on the Accounts Receivable side through subscriptions, but there is no equivalent capability on the Accounts Payable side. Vendors that need to be paid on a recurring basis—either as a fixed amount or based on shipment activity—cannot be modeled natively and require manual workarounds. Net invoice is NOT required - if someone needs both receivable and payable, they will be 2 different subscriptions, one receivable and one payable.<h2>Solution</h2>Extend the existing subscription and AI Billing Engine so it can generate recurring vendor bills using the same lifecycle as recurring invoices. The system should be able to create either an invoice or a bill from a subscription, based solely on configuration, without introducing new billing logic or math. A new attribute called billing_type will be added to the subscription object with two possible values of: [receivable, payable]. <h2>DOD:</h2><ol><li>I can create a vendor subscription using the same configuration flow as AR subscriptions.</li><li>I can select a vendor when creating the subscription.</li><li>I can configure a recurring bill plan for the subscription.</li><li>The system generates recurring bills automatically.</li><li>I can view the generated bills in Accounts Payable.</li><li>Bills can be calculated as a fixed recurring amount (e.g. $100 per month).</li><li>Bills can be calculated dynamically based on shipment quantities using simple rate logic.</li></ol>

Recurring bills

<h2>Problem Statement</h2>To automate vendor payouts via ACH, the system needs a secure, standardized place to store and validate banking information. Today, there is no canonical source of truth for vendor payout details, making bulk payment exports unreliable and manual.<h2>User Story</h2>As a finance user,I want to store and manage ACH payout details on a vendor,so the system can automatically generate payment batches and ACH exports.<h2>Scope / Behavior</h2>Vendor Payout DetailsExtend Vendor records to support ACH payout configuration.Stored fields (example for ACH):<ol><li>Account holder name</li><li>Bank name</li><li>Routing / transit number</li><li>Account number (securely stored / tokenized)</li><li>Account type (Checking / Savings)</li><li>Currency</li><li>Country</li><li>Payout method status (Enabled / Disabled / Invalid)</li><li>Vendor internal identifier (Used as NACHA Individual Identification Number/ System-generated (no manual input))</li><li>Transaction type: Credit only (vendor payouts)</li></ol>The system must store the following authorization metadata per vendor:- Authorization status (Authorized / Revoked / Pending) - Set explicitly by authorized admin users- Authorization timestamp - System-generated when status becomes Authorized- Authorization method - Selected by admin from a predefined list (e.g. Written, Electronic)<ol><li>The ACH entry form should live on the Vendor create/edit page, under Personal Settings → Financial Settings.</li></ol><ol><li> "ACH Ready / Not Ready" indicator should be surfaced in vendor list/ vendor profile.</li></ol><blockquote>Exact field set may vary by region (US, CA), but must support ACH-NACHA exports.To support NACHA exports, Pelcro must store vendor bank details plus ACH authorization metadata and vendor identification,</blockquote><h2>Definition of Done (DoD)</h2><ol><li>✔ Vendor records support storing ACH payout details</li><li>✔ Sensitive banking data is securely stored and masked</li><li>✔ System can determine if a vendor is ACH-payable</li><li>✔ Vendors without valid ACH info are excluded from payment batches</li><li>✔ ACH details are referenced (not duplicated) in payment batches and exports</li></ol>

Vendors ACH Entry (NACHA compliance)

🔍 Problem StatementAs a publisher, I experience challenges mapping subscriber addresses to carriers/vendors, which results in unnecessary daily manual assignments, routing errors, and fulfillment delays. 💡 User Story<ol><li>As an operations user, I want addresses to be automatically classified and assigned to the correct vendor using delivery prompts, so that vendor mapping is consistent and no longer requires daily manual effort.</li><li>As an admin user, I want to define delivery service areas per vendor using standard postal formats, so that assignment rules are structured and easily maintained.</li></ol> 🎯 Definition of Done (DoD)✔ A new field, <code>vendor_id</code>, is added to the Shipping Address object:<ol><li>Readable and writable via the Pelcro Core API</li><li>Editable and visible in the Address view on the platform</li><li>Must reference a valid existing Vendor ID</li></ol> ✔ Extend the Vendor object to support one Delivery Prompt per vendor:<ol><li>Admins can create, edit, and delete a single delivery prompt per vendor</li><li>Prompts define service zones using standard mailing formats:</li><li>ZIP code ranges (e.g., <code>04401–04412</code>)</li><li>Street address ranges (e.g., <code>Main St 100–399</code>)</li><li>City or county filters (e.g., <code>Bangor</code>, <code>Penobscot County</code>)</li></ol> ✔ When an address is created or updated:<ol><li>It is evaluated against all existing Delivery Prompts across vendors by an AI agent</li><li>The first matching vendor (based on internal order) will be assigned as the <code>vendor_id</code></li><li>If no match is found, <code>vendor_id</code> remains empty</li><li>If multiple matches occur, the first match will be used by default</li><li>Each address can be assigned to only one vendor</li></ol> ✔ Updating a Vendor’s Delivery Prompt does not trigger re-evaluation of existing addresses.<ol><li>If reclassification is required, it must be done manually via Core API or bulk update tools.</li></ol> ✔ The following areas will reflect <code>vendor_id</code>:<ol><li>List &amp; Fulfillment Exports (for <code>Mailable: Local Delivery</code> lists)</li><li>List Builder (filter by vendor ID or blank vendor)</li><li>Address View – displays and allows editing of <code>vendor_id</code></li><li>Vendor View – displays the list of matched addresses</li></ol>

[AI] Delivery Agent

<h2>Problem Statement</h2>Pelcro’s checkout flow currently allows logged-in subscribers with an active subscription to initiate the purchase of a new plan without being made aware that they already have an active subscription.<h2>User Story</h2>As a subscriber using the checkout flow,I want to clearly see that I already have an active subscription,so that I avoid purchasing duplicate or unnecessary plans.<h2>Proposed Behavior</h2>When a logged-in user with at least one active subscription opens the product or plan selection interface (React Elements):Informational BannerA visible informational banner appears at the top of the product/plan selection modal containing:<ol><li>Text: “You are already subscribed to: {Active Plan Name}”</li></ol>No actions, buttons, or links are included.<h2>Logic Rules</h2><ol><li>Banner displays only for logged-in users with active subscriptions.</li><li>If multiple active subscriptions exist:</li><li>Display the most recently created active subscription.</li><li>No backend or API changes required.</li></ol><h2>Definition of Done (DoD)</h2>UI Implementation (React Elements)<ol><li>Implement a simple informational banner at the top of the product/plan selection modal.</li><li>Banner includes:</li><li>“You are already subscribed to: {Plan Name}”</li><li>Styling should follow Pelcro’s general UI guidelines.</li><li>No interactive elements are added.</li></ol>Functional Behavior<ol><li>Banner is informational only.</li><li>Checkout behavior for selecting plans remains unchanged.</li></ol>Edge Conditions<ol><li>Banner is hidden when the user has no active subscription.</li><li>Banner dynamically loads based on the subscription status available in Elements.</li></ol><h2>Affected Components</h2><ol><li>UI: Pelcro React Elements (checkout flow)</li><li>API: None</li><li>SDK: None</li><li>Backend: None</li></ol>

Prevent Duplicate Subscriptions in Checkout Flow

<h2>Problem Statement</h2>Administrators need the ability to set or backdate the subscription start date directly from the platform. The current platform does not provide a controlled way to adjust <code>start_date</code>, creating gaps when aligning entitlement periods or correcting subscription timelines. The feature must also be supported through the Subscription Create API endpoint, ensuring API-first consistency.<div data-type="horizontalRule"><hr></div><h2>User Story</h2>As an admin or integrator, I want to explicitly set the subscription start date (including backdating) via the platform UI and the Subscription Create API, so that subscription timelines can be accurately initialized without relying on workarounds.<div data-type="horizontalRule"><hr></div><h2>Definition of Done (DoD)</h2><h3>1. Functional Requirements</h3><ul><li>The platform allows administrators to set or backdate the subscription <code>start_date</code>.</li><li>The Subscription Create API accepts an optional <code>start_date</code> parameter.</li><li>Changing the start date does not modify:<ul><li>Invoice start date</li><li>Invoice line-item periods</li><li>Historical invoice data</li></ul></li></ul><h3>2. Renewal Logic</h3><ul><li>Renewal date is based on the subscription's start date, including backdated values. Example: Backdating to Aug 1 → next renewal occurs Aug 1 of the next cycle.</li></ul><h3>3. Guardrails</h3><ul><li>Start-date modification (UI or API) allowed only when:<ul><li>The subscription is not set to auto-renew, and</li><li>No renewal phase or future renewal event is scheduled.</li></ul></li><li>Operation must be blocked when renewal logic depends on the existing start date.</li></ul><h3>4. Scope</h3><ul><li>Applies to all plan types (shipment-based and time-based).</li><li>Implemented in:<ul><li>Platform UI (admin-level controls)</li><li>Subscription Create API</li></ul></li></ul><h3>5. UI Note</h3><ul><li>Where applicable, the UI must clearly state: “Start date modifications do not affect invoice dates.”</li></ul>

Subscription Start-Date Override (Platform + API)

Problem StatementPelcro clients are not able to project their subscriber behavior into the future because they don't understand historical numbers and current projected number.User Story<ol><li>As a Pelcro client, I want to understand how many subscriptions were retained and churned in a given period</li></ol>DoD<ol><li>Create a Subscription Health report on Pelcro platform. Pelcro client can select their required date range and interval. The output will be a table based on every interval valid in the selected date range:</li><li>If user selects a date range of January 1, 2024 to December 31, 2024 with an interval of Monthly, then the table below will be January 1-January 31, February 1 - Feb 29, etc..</li><li>We generate a table with the variable below based on database queries</li></ol><table style="minWidth: 75px"><colgroup><col><col><col></colgroup><tbody><tr><td colspan="1" rowspan="1">Name</td><td colspan="1" rowspan="1">Variable</td><td colspan="1" rowspan="1">Description</td></tr><tr><td colspan="1" rowspan="1">Opening Actives</td><td colspan="1" rowspan="1">OA</td><td colspan="1" rowspan="1">Subscriptions active at the start of period</td></tr><tr><td colspan="1" rowspan="1">New Starts</td><td colspan="1" rowspan="1">NS</td><td colspan="1" rowspan="1">Subscriptions created during period</td></tr><tr><td colspan="1" rowspan="1">Churned (Opening Cohort)</td><td colspan="1" rowspan="1">CO</td><td colspan="1" rowspan="1">Subscriptions that were active at the start but ended during the period and did not renew</td></tr><tr><td colspan="1" rowspan="1">Churned (In-Period)</td><td colspan="1" rowspan="1">CI</td><td colspan="1" rowspan="1">Subscriptions that started and ended during the period (short-term churn)</td></tr><tr><td colspan="1" rowspan="1">Closing Actives</td><td colspan="1" rowspan="1">CA</td><td colspan="1" rowspan="1">Subscriptions active at the end of period</td></tr><tr><td colspan="1" rowspan="1">Closing Actives (Opening Cohort)</td><td colspan="1" rowspan="1">CAO</td><td colspan="1" rowspan="1">Subscriptions that started the period and are still active at end of period</td></tr></tbody></table><ol><li>In order to audit this and verify it is true, verify that CA = OA + NS - CO - CI</li><li>All variables in table above must be exportable</li></ol>3. Generate retention and churn rate numbers based on the table above<ol><li>Subscription Retention Rate = (OA - CO)/OA</li><li>Total Retention Rate = CA / (OA + NS)</li><li>Subscription Churn Rate = CO / OA</li><li>In-Period Churn Rate = CI / NS</li><li>Total Churn Rate = (CO + CI) / (OA + NS) Here is a quick mockup:<a target="_blank" rel="noopener noreferrer nofollow" class="ProsemirrorEditor-link link" href="https://v0-subscription-health-report.vercel.app/">https://v0-subscription-health-report.vercel.app/</a></li></ol>

Subscription Health Report for Retention and Churn Insights

<h3>Problem Statement</h3>Currently, coupon fields such as maximum redemptions and expiration date cannot be edited once a coupon has been created. This limitation forces users to create new coupons whenever adjustments are needed — leading to operational inefficiencies, fragmented analytics, and increased risk of configuration errors. Additionally, coupon expiration only supports date-based UTC values, without the ability to specify a time component, making it difficult for publishers to manage time-sensitive promotions accurately.<div data-type="horizontalRule"><hr></div><h3>User Story</h3>As a subscription manager, I want to be able to edit coupon configuration fields such as maximum redemptions and expiration date/time so that I can manage promotions flexibly without creating duplicate coupons or disrupting active campaigns.<div data-type="horizontalRule"><hr></div><h3>Definition of Done (DoD)</h3>✅ API Layer<ul><li>Add support for editable coupon fields via <code>PATCH /coupons/:id</code> endpoint.</li><li>Allow updates to:<ul><li><code>max_redemptions</code></li><li><code>expires_at</code> (date + time support in ISO8601 format)</li></ul></li><li>Include validation logic to prevent retroactive invalid states (e.g., editing expired coupons to past dates).</li></ul>✅ Platform (Dashboard UI)<ul><li>Update the coupon edit modal/form to allow modification of:<ul><li>Maximum redemptions (integer field with validation)</li><li>Expiration date + time (datetime picker in local timezone)</li></ul></li><li>Ensure that audit logs capture all field changes (e.g., “Max redemptions updated from 100 → 150 by [user_email]”).</li></ul>✅ Data &amp; Audit<ul><li>Maintain versioning for coupon updates for traceability.</li><li>Expose updated timestamps (<code>updated_at</code>) in API responses.</li></ul><h3><s>Problem Statement</s></h3><s>Currently, coupon fields such as </s><s>maximum redemptions</s><s> and </s><s>expiration date</s><s> cannot be edited once a coupon has been created. This limitation forces users to create new coupons whenever adjustments are needed,</s><s>Feedback:</s><s>Would love to be able to edit coupon fields such as max redemption and expire date</s>

Ability to Edit Coupons and Re-Enable Codes

Kristie Wahlquist

<h2>🔍 Problem Statement</h2>As a Pelcro admin, I experience the inability to apply an existing customer balance to an open invoice that was generated before the balance existed, which results in inefficient manual workarounds, disrupted billing flows, and increased operational overhead.<div data-type="horizontalRule"><hr></div><h2>💡 User Story</h2>As a Pelcro admin, I want to apply an existing customer balance to an already open invoice, so that I can settle outstanding charges accurately without canceling subscriptions or recreating invoices.<div data-type="horizontalRule"><hr></div><h2>🎯 Definition of Done (DoD)</h2>A feature is done when:✔ Given a customer with an available customer balance and an open/past_due invoice generated prior to the balance being added, the admin can apply the balance to the invoice, then the invoice reflects a partial or full payment using that balance.✔ Given the customer balance fully covers the invoice amount, the admin can apply the balance, then the invoice is marked as <code>paid</code> with no additional payment required.✔ Given the customer balance partially covers the invoice amount, the admin can apply the balance, then the remaining amount can be settled by either:<ul><li>Charging the customer’s default credit card (via Charge Customer), or</li><li>Recording an offline payment (via Mark as Paid).</li></ul>✔ This change will impact Admin UI and API, specifically:<ul><li>Admin invoice payment actions</li><li>Customer balance application logic</li><li>Invoice payment state transitions ([clarify API endpoint(s)]).</li></ul>✔ This solution will include the following limitations:<ul><li>Customer balance cannot be applied to <code>void</code>, <code>uncollectible</code>, or <code>paid</code> invoices.</li><li>Customer balance cannot exceed the invoice outstanding amount.</li><li>Automatic balance application to historical invoices is not supported (manual admin action only).</li><li>Subscriber-facing UI behavior remains unchanged.</li></ul>

Allow Admins to Apply Customer Balance to Pre-Existing Open Invoices

Galal Abdo

Problem Statement: During a fulfillment run, a client with an open invoice receives a hard copy of the invoice with their shipment. Currently, there is no option to mass print all open invoices to ship with the fulfillment; each one has to be done manually and separately.Suggestion: A button to print all open invoices in 1 PDF to be sent to the print house with the fulfillment list.

Ability to Mass print all Open Invoices in PDF format

Ahmed Soliman

<h2>Problem Statement</h2>Today, Pelcro requires subscriptions to start immediately upon creation, which limits operational flexibility for customer support and sales teams. Many businesses need to create subscriptions in advance with a specific future start date—for example, when a customer signs up early but requests access to begin later. <h2>User Story</h2>As a subscription operations,I want to create a subscription with a defined future start date,So that subscription access, billing, and renewal periods begin on the requested date without manual follow-up or adjustments.<h2>Subscription Creation &amp; Configuration </h2>For accounts using pelcro’s engine<ol><li>A new input field, “Scheduled start date”, is available when creating a subscription.</li><li>When a scheduled start date is set, the subscription is created in a new <code>scheduled</code> status.</li><li>The subscription phase does not start until the scheduled start date.</li><li>No subscriber access is granted before the scheduled start date.</li></ol><h2> ### Billing &amp; Invoicing </h2><ol><li>Introduce a new option when creating a subscription:</li><li>Billing behavior</li><li>☐ Bill immediately (advance invoicing)</li><li>☐ Bill starting on the selected date </li><li>If Bill immediately is selected:</li><li>Current behavior remains unchanged (invoice gets generated &amp; pays now)</li><li>If Bill starting on selected date is selected:</li><li>No invoice is generated at creation</li><li>Billing, invoicing, and renewal cycles are anchored to the selected date</li><li>The subscription is created with a scheduled status until the anchor date</li><li>This allows all invoices to be generated on the same weekday, regardless of when the subscription is created</li><li>Should work with AI plans</li></ol> Activation &amp; Revenue Recognition <ol><li>On the scheduled start date:</li><li>The subscription automatically transitions from <code>scheduled</code> to <code>active</code>.</li><li>The first subscription phase begins.</li><li>Revenue recognition starts on the scheduled start date.</li><li>Subscription renewal dates are anchored to the scheduled start date.</li></ol> APIs &amp; Status Exposure <ol><li>The new <code>scheduled</code> status is returned consistently across:</li><li>Open API</li><li>Core API</li><li>Webhooks</li><li>Status behavior is consistent with existing subscription statuses (e.g., <code>active</code>, <code>canceled</code>, <code>expired</code>).</li></ol> Backward Compatibility <ol><li>Existing subscription behavior remains unchanged when no scheduled start date is provided.</li><li>No breaking changes are introduced to existing APIs or integrations.</li></ol>

Subscription Start-Date in The Future (Platform + API)

<h3>Problem Statement</h3>Currently, subscription-related events/logs are not visible in the subscription details view, making it difficult to understand changes, investigate issues, and answer questions about a subscription’s history. User StoryAs an admin I want to view activity logs in the subscription details page So that I can track all subscription events and changes in one place.

Introduce Activity logs in subscriptions details view

Problem Statement 1 — EligibilityRevenue should only be recognized for invoices that have been successfully fully paid (or partially paid, TBD); unpaid or failed invoices must not contribute to recognized revenue.Problem Statement 2 — TimingRevenue recognition must begin on the invoice payment date, not on the invoice creation date, when payment succeeds after an initial failure.Problem Statement 3 — Subscription Access &amp; Term AlignmentSubscription access and the subscription term must begin on the payment success date; if payment succeeds after the initial subscription attempt, the subscription start and renewal dates should shift to align with the payment date.<div data-type="horizontalRule"><hr></div>User Story 1 — Revenue EligibilityAs a finance user, I want revenue to be recognized only for invoices that are paid, so that unpaid or failed invoices do not count toward recognized revenue.User Story 2 — Revenue TimingAs a finance user, I want revenue recognition to start on the invoice payment date, not the invoice creation date, so that revenue timing reflects when payment actually succeeds.User Story 3 — Subscription Access &amp; Term StartAs a subscriber, I want my subscription access and renewal period to begin when my payment succeeds, so that my access duration aligns with when I actually paid.<div data-type="horizontalRule"><hr></div>Solution 1: Revenue recognition (Problem 1)Revenue is recognized only for invoices with <code>status = paid</code> (Partial payments: TBD). No revenue is recognized for unpaid or failed invoices, and no revenue is backdated to periods before payment.Solution 2: Subscription term alignment (Problem 2)On the first successful payment, the subscription term is anchored to the payment date by setting <code>invoice.current_period_start = invoice.paid_at</code> and <code>invoice.current_period_end = invoice.paid_at + plan_interval</code>, and copying these values to the subscription. This ensures access starts when the user actually pays and renewals align to that date (e.g., Jan 7 → Feb 7).Solution 3: Subscription activation &amp; access (Problem 3)When a subscription is created, payment is attempted immediately, but the subscription remains incomplete and grants no access until the first payment succeeds. If payment fails, the subscription stays pending. When payment succeeds (<code>invoice.paid_at</code>), the subscription becomes active.<h2>Definition of Done — Product-level Revenue Recognition Strategy</h2>Configuration<ol><li>A new product-level dropdown labeled “Revenue recognition strategy” exists on the Product configuration page.</li><li>The dropdown has two options:</li><li>Invoice-creation-based (default) — preserves existing behavior.</li><li>Invoice-payment-based — enables payment-anchored behavior.</li><li>All existing products default to Invoice-creation-based with no behavior change.</li></ol>Invoice creation date (Default)<ol><li>Revenue recognition behavior remains unchanged.</li><li>Unpaid or failed invoices continue to be treated according to current logic.</li><li>Subscription activation, access, and term dates behave exactly as today.</li></ol>Payment creation date (New)<ol><li>Only invoices with <code>status = paid</code> are included in revenue recognition.</li><li>Unpaid or failed invoices are automatically excluded from revenue reports.</li><li>Revenue recognition starts at <code>invoice.current_period_start</code>.</li><li><code>invoice.current_period_start</code> is set to <code>invoice.paid_at</code>.</li><li><code>invoice.current_period_end</code> is set to <code>invoice.paid_at + plan_interval</code>.</li><li>Subscription activation occurs only after the first invoice is paid.</li><li>Subscription <code>current_period_start</code> and <code>current_period_end</code> match the invoice period.</li><li>Subscriber access begins at <code>current_period_start</code>.</li></ol>Backward Compatibility<ol><li>No breaking changes are introduced.</li><li>Existing products and subscriptions continue to use Invoice-based behavior unless explicitly updated.</li></ol>Acceptance Criteria<ol><li>Switching a product to Invoice-payment-based immediately enforces payment-anchored access, term dates, and revenue filtering.</li><li>Revenue reports correctly exclude unpaid invoices for Payment-based products.</li><li>Revenue reports remain unchanged for Invoice-based products.</li></ol>

Cash Revenue recognition

<h2>Problem Statement</h2>Today, Pelcro does not support bulk charging of invoices by card. As a result, customers must charge a card in bulk on Stripe and then manually mark each invoice as paid offline in Pelcro, which is time-consuming, error-prone, and inefficient for high-volume billing operations.<h2>User Story</h2>As a finance or operations user,I want to select multiple invoices and pay them in bulk within Pelcro,So that I don’t need to charge cards in Stripe separately and then manually mark each invoice as paid offline.<h2>Definition of Done (DoD)</h2>For Pelcros billing engine:<ol><li>Users can select multiple invoices from the invoices tab view under the customer's profile.</li><li>A bulk action is available to pay selected invoices.</li><li>Admins should be able to choose “Charge card” or “Pay offline”.</li><li>Bulk payment supports charging the customer’s saved payment method (e.g., card) or marking them as paid (offline payment)</li><li>All selected invoices are updated to a paid state upon successful processing.</li><li>No changes to existing single-invoice payment behavior.</li><li>Bulk payment actions are logged and auditable.</li></ol>

Ability to charge a card separately

🔍 Problem StatementCurrently, when end users cancel their subscriptions, we do not collect structured data on the reasons for cancellation. This limits our ability to understand customer churn, identify patterns, and implement improvements to retain subscribers.💡 User StoryAs a business owner,I want a required exit survey that asks customers their reason for cancelling via a dropdown with predefined options, plus an open-text field if “Other” is selected,so that I can better understand why customers churn and use these insights to improve retention strategies. 🎯 Definition of Done (DoD)A feature is considered done when:<ul><li>A required field is presented to users when they attempt to cancel a subscription.</li><li>The field is a dropdown containing a list of reasons configured through the platform.</li><li>If “Other” is selected, an open-text input field appears, allowing the user to specify their reason.</li><li>The open-text input field is required when other is selected.</li><li>The validations happens only on the UI strictly and not on the Open API.</li><li>This change needs to be backward compatible with custom UIs and older react elements versions.</li><li>The selected reason (and optional free-text entry) is stored in the subscription object and is accessible in subscription exports.</li></ul>

Add Cancellation Reason in new UI

🔍 Problem Statement The Pelcro JavaScript SDK (<code>pelcro</code> package) can be further optimized to improve JavaScript loading performance and enhance the end-user experience of the Pelcro interface. The current build setup and testing framework work reliably, but they do not take full advantage of the latest improvements in the JavaScript ecosystem. This creates opportunities to reduce bundle size, improve loading speed, and streamline developer workflows. 💡 User Story As a Pelcro end user, I want the SDK to load quickly and render the user interface smoothly, so that my interaction with subscriptions, paywalls, and account features feels seamless.As a developer integrating Pelcro, I want the SDK to be built with modern tooling and testing frameworks, so that I can confidently deliver a fast, reliable, and secure experience to my customers. 🎯 Definition of Done (DoD) A feature is done when:✔️ Modernize tooling<ul><li>Upgrade Node.js to the current Long Term Support (LTS) release.</li><li>Switch from Yarn to pnpm for faster and more efficient dependency management.</li><li>Update major dependencies (Babel, ESLint, etc.) to their latest stable versions.</li></ul>✔️ Modernize build system<ul><li>Upgrade from Webpack 4 to Webpack 5 for better performance and compatibility.</li><li>Migrate to <code>webpack.config.mjs</code> with ES modules and native <code>import</code> syntax.</li></ul>✔️ Dependencies streamlined<ul><li>Remove any unused dependencies or devDependencies.</li><li>Update remaining dependencies in <code>package.json</code> to their latest stable versions.</li></ul>Test Cases<ol><li>Added unit test coverage for all UI components listed in the coverage report.</li><li>Verified rendering, props handling, and default states.</li><li>Covered edge cases for conditional rendering and error handling.</li><li>Ensured event handlers and callbacks are triggered correctly.</li><li>Validated data formatting and helper utilities with both valid and invalid inputs.</li><li>Increased overall branch and function coverage across the UI component library.</li></ol>

Modernizing the Pelcro JavaScript SDK for Faster Performance

🔍 Problem StatementCurrently, the platform does not support refunding customer balances directly back to their payment cards.This limitation requires manual intervention or external processing to return unused balances, which increases operational overhead, delays refunds, and may create confusion or dissatisfaction for customers expecting automatic refunds to their original payment method.💡 User StoryAs a customer support or billing administrator,I want to be able to refund a customer’s balance directly to their saved or original payment card through the platform,so that refunds are processed seamlessly, accurately, and without manual handling outside the system🎯 Definition of Done (DoD) A feature is considered complete when: ✔ Given a payment whose destination was a customer balance,→ The “Refund” button appears in the Admin Dashboard as it does for normal payments. ✔ When an admin initiates a refund,→ The refund amount defaults to the original charge amount.→ If the customer balance is higher than the charge, only the charge amount is refundable (no over-refunds). ✔ Refunds may be full or partial, but cannot exceed the original charge amount. ✔ Each refund is tied to its originating payment and processed via the original payment method and gateway used for the charge. ✔ The refund event triggers (<code>charge.refunded</code>) containing: <ol><li>Refund amount</li><li>Customer ID</li><li>Masked card details</li><li>Payment and refund transaction IDs</li><li>Timestamp</li></ol> ✔ Accounting impact matches the current refund mechanism for standard payments. 🧩 Impacted Components <table style="minWidth: 50px"><colgroup><col><col></colgroup><tbody><tr><td colspan="1" rowspan="1">Component</td><td colspan="1" rowspan="1">Description</td></tr><tr><td colspan="1" rowspan="1">UI</td><td colspan="1" rowspan="1">Display “Refund” button in platform for payments credited to customer balance.</td></tr><tr><td colspan="1" rowspan="1">Backend </td><td colspan="1" rowspan="1">Implement logic to determine original payment method and issue refund via gateway.</td></tr><tr><td colspan="1" rowspan="1">Webhooks</td><td colspan="1" rowspan="1"> <code>charge.refunded</code> should be fired</td></tr><tr><td colspan="1" rowspan="1">Accounting / Reports</td><td colspan="1" rowspan="1">Ensure refund transactions appear consistently in reports and ledger exports.</td></tr></tbody></table> ⚙️ Limitations / Notes <ol><li>Applies to payments originally charged and credited to customer balance.</li><li>Refunds cannot exceed the original charge amount.</li><li>Refund logic must respect existing refund policies and gateway constraints.</li></ol><div data-type="horizontalRule"><hr></div>Product Notes<ol><li><code>Designs/Resources/Links/Wireframes/Mockups</code> </li><li><code>Client Users Watchlist</code></li></ol><div data-type="horizontalRule"><hr></div>Development Notes<ol><li><code>Components which the feature touches</code></li><li><code>Details on backend/frontend/API/webhooks/SDK implementation</code></li><li><code>Error handling</code></li><li><code>Logging events</code></li><li><code>Technical doc links which have been updated</code></li><li><code>Breaking changes</code></li><li><code>Usability risks/limitations</code></li><li><code>Impact analysis:</code></li><li><code>(Sample)Added a new JSON key to the object stored in DB, therefor, either a guard in code needs to be added or old lists using Expiry object needs to be adjusted and adding the new JSON key to them.</code></li><li><code>QA steps needed to validate:</code></li><li><code>Check functionality of lists created prior this deployment</code></li></ol><div data-type="horizontalRule"><hr></div>QA Notes<ol><li><code>Planned Test cases: &lt;Testrail link&gt;</code></li><li><code>Initial Test run: &lt;Testrail link&gt;</code></li><li><code>Additional Test run(s): &lt;Testrail link&gt;</code></li></ol><div data-type="horizontalRule"><hr></div>Open Questions<ol><li><code>&lt;Name of concerned member&gt; Question</code></li></ol>

Enable Refund of Customer Balances to Payment Cards

<h2>📝 Problem Statement</h2>Fetching Site information can currently take up to a full second. This delay slows down loading, parsing, and execution across the UI.<div data-type="horizontalRule"><hr></div><h2>👤 User Story</h2>As a business owner, I want the Site Information endpoint to respond quickly, So that my customers experience quicker page loads and smoother interactions in the UI.<div data-type="horizontalRule"><hr></div><h2>✅ Definition of Done (DoD)</h2><ul><li>Offload cacheable endpoints to Cloudflare for ultra-fast response times.</li><li>Store and update JSON in real-time using R2 Object Storage.</li><li>Serve responses with fast edge performance via Workers.</li><li>Enable real-time cache invalidation with Cache-Control, ETag, and versioning strategies.</li><li>Ensure fallback to origin works seamlessly via Worker logic.</li><li>Achieve sub-50ms response times with Cloudflare global edge + object prefetching.</li></ul><h2>Test Cases</h2><ul><li>Validate headers in response are served through cloudflare</li><li>Validate paymentGateway objects keys Addition/updates/deactivation in the response json.</li><li>Validate random keys Addition/updates from site info on the response (google_id, auth0_id...etc)</li><li>Validate products Addition/updates/deletion impact on json response</li><li>Validate plans Addition/updates/deletion impact on json response</li><li>Validate paywalls Addition/updates/deletion impact on json response</li><li>Validate the above against accounts on single site</li><li>Validate the above against accounts with multiple sites with objects (products, plans, paywall) to reflect on both sites</li><li>Validate the above against accounts with multiple sites with objects (products, plans, paywall) to reflect on a single sites</li></ul>

Faster Loading for Site information

📝 Problem StatementCurrently, subscribers do not have a streamlined way to upgrade their plans or explore additional products within a self-serve interface. This creates friction, increases dependency on support teams, and limits upsell opportunities.👤 User StoryAs a subscriber,I want the ability to upgrade my plan and explore new products through a modern self-serve interface,so that I can manage my subscriptions independently and access new offerings without needing manual assistance. 🎯 Definition of Done (DoD)<ol><li>A self-serve UI is implemented in the new React Elements for upgrading plans and browsing products.</li><li>A Change Plan button is available in the new UI for subscribers.</li><li>When clicked, the user can view available upgrade products.</li><li>A proration invoice should be created with the new amount after selecting the new plan.</li><li>The plan selection flow in the new UI mirrors the existing platform behavior (e.g., eligibility checks, upgrade rules, proration).</li><li>User receives a confirmation message of the plan change (e.g., “You’ve successfully upgraded to Plan X”).</li><li>The subscriber’s account reflects the updated plan in real time.</li><li>The system validates and confirms the change before applying it to the subscriber’s account.</li><li>UI is tested across supported devices/browsers to ensure a smooth self-serve experience.</li><li>Documentation and developer guides are updated to cover new React Elements implementation.</li></ol>

Enable Self-Serve Plan Upgrades in default UI

Story Allow change in roles for collaborators rather than deleting and re-adding

Edit collaborator role

🔍 Problem StatementCurrently, the Carrier Routes field is not included in the Fulfillments Export, even when Address Cleansing is enabled. This limits the usefulness of the export for distribution and delivery optimization.👤 User StoryAs a fulfillment manager, I want the Carrier Routes field to be included in the Fulfillments Export when Address Cleansing is enabled, so that I can provide more accurate delivery instructions and streamline distribution.🎯 Definition of Done (DoD)A feature is done when:<ol><li>When Address Cleansing is enabled:</li><li>The Carrier Routes field is included in the Normal Fulfillments Export.</li><li>The new field is appended to the export in a way that avoids breaking changes to existing fields.</li><li>Verified in staging that exports with Address Cleansing enabled contain Carrier Routes, and exports without Address Cleansing remain unchanged.</li><li>Documentation for the Fulfillment Export is updated to reflect the new field.</li></ol>Test Cases: Ensure that when Address Cleansing is enabled, the Fulfillments Export includes the Carrier Routes field. Ensure that the Carrier Routes field is appended at the end of the Fulfillments Export to prevent breaking changes. Ensure that the Carrier Routes values in the export match the actual carrier route data produced by Address Cleansing. Ensure that existing columns in the Fulfillments Export remain unchanged in structure and order, with only Carrier Routes added at the end. Ensure that if a carrier route is not available for an address, the Carrier Routes field appears blank (not an error).

Add Carrier Routes to Fulfillment Export when Address Cleansing is Enabled

<h2>Problem Statement</h2>Currently, Pelcro users cannot view a consolidated summary of all customer ending balances. This limits visibility into outstanding amounts and requires manual exports or database queries. A dedicated report is needed under the Accounting tab to improve transparency, efficiency, and decision-making. <h2>User Story</h2>👤 User StoryAs an accounting/finance userI want to get a “Customer Balance Summary Report” under the Accounting tabSo that I can quickly see all customers’ ending balances in one place without exporting data manually. 🎯 Definition of Done (DoD) A feature is considered done when:<ul><li>A new page labeled “Reports” is available under the Accounting tab, using the new UI template.</li><li>The page includes a Customer Balance Summary Report which should have all the following attributes:<ul><li>Customer ID</li><li>Currency</li><li>Ending Balance</li><li>Customer Email</li><li>Plan ID</li><li>Product ID</li><li>Subscription Plan Amount</li><li>Subscription Product Name</li><li>Subscription Plan Nickname</li><li>Outstanding Invoices Count</li><li>Default Payment Method</li><li>Customer Created Date</li><li>Expiry Date of Last Active Subscription</li><li>End Date of Expired Subscriptions</li><li>Has Active Subscription</li><li>Number of Active Subscriptions</li><li>Last Active or Current Subscription ID</li></ul></li><li>The export will be sorted in descending order so finance teams see the highest outstanding balances first.</li><li>The UI follows the new template design system (consistent typography, layout, components).</li><li>The feature is tested across major browsers and devices to ensure responsiveness and usability.</li><li>Documentation is updated to explain where the report is located and how to use it.</li></ul>

Customer Balance Summary Report

<h2>🔍Problem Statement</h2>Currently, Pelcro invoices do not support adding invoice notes directly on the invoice. This limits flexibility for businesses that need to include contextual details (e.g., billing references, legal notes, or custom instructions).<h2>👤 User Story</h2>As a business owner,I want the ability to add and update invoice notes directly within the invoice view,So that I can provide additional context or instructions that are clearly displayed on the invoice and carried over to the PDF version.🎯 Definition of Done (DoD)<ol><li>Introduce ability to add invoice notes on the invoice view similar to setting the PO value in the invoice view.</li><li>The invoice notes should appear in the PDF.</li><li>You can update the invoice notes after creating it similar to PO.</li><li>Invoice notes are saved to the invoice record and retrievable via the Core API.</li></ol>Test cases: General Invoice Notes (Core Cases)<ul><li>C5876: Verify adding a note on an invoice saves successfully.</li><li>C5877: Verify the note persists after refresh/reopen.</li><li>C5878: Verify updating a note overwrites the old content.</li><li>C5879: Verify clearing a note removes it from the invoice.</li><li>C5880: Verify the note appears on the PDF after saving.</li><li>C5881: Verify updated/cleared notes refresh on the next PDF download.</li><li>C5882: Verify the Default UI download includes the note.</li><li>C5883: Verify Core API (<code>GET /invoices/{id}</code>) returns the note field.</li><li>C5884: Verify creating/updating a note via Core API reflects in Platform &amp; PDF.</li><li>C5885: Verify multiline, special characters, and long notes render correctly in UI &amp; PDF.</li><li>C5886: Verify invoice state rules (draft/open/paid) are respected when editing notes.</li></ul><div data-type="horizontalRule"><hr></div><h3>Advance Invoice (Manual Renewal Action)</h3><ul><li>C5887: Verify advance invoice supports adding a note and saving it.</li><li>C5888: Verify note appears on the PDF and updates on re-download.</li><li>C5889: Verify note is returned via Core API.</li><li>C5890: Verify adding/updating via API reflects in Platform &amp; PDF.</li><li>C5891: Verify note is visible when opening invoice from the renewal timeline entry.</li></ul><div data-type="horizontalRule"><hr></div><h3>Automatic Renewal Invoice (System-Generated)</h3><ul><li>C5892: Verify adding/updating/clearing a note works on auto-generated invoices.</li><li>C5893: Verify note appears on PDF and updates correctly.</li><li>C5894: Verify Core API returns the note value.</li><li>C5895: Verify adding note after auto-generation still syncs to PDF/API.</li></ul><div data-type="horizontalRule"><hr></div><h3>Standalone Invoice</h3><ul><li>C5896: Verify adding/updating/clearing notes works like other invoice types.</li><li>C5897: Verify note appears on PDF and updates correctly.</li><li>C5898: Verify note is retrievable via Core API.</li><li>C5899: Verify long/multiline/special notes render correctly without layout issues.</li></ul><div data-type="horizontalRule"><hr></div><h3>Invoice from eCommerce Order</h3><ul><li>C5900: Verify adding/updating/clearing a note on eCommerce invoice works and persists.</li><li>C5901: Verify note appears on PDF and reflects updates.</li><li>C5902: Verify Core API (<code>GET /invoices/{id}</code>) returns the note.</li><li>C5903: Verify note remains intact through eCommerce flows (refunds, partial refunds).</li><li>C5904: Verify Default UI download includes the note. </li></ul>

Introduce ability to add invoice notes on the invoice PDF

🔍 Problem StatementAs an internal finance team, I experience inefficiencies and manual work when managing payments to vendors, which results in delayed payments and inconsistent records.💡 User StoryAs an admin user, I want to create, manage, and track vendor bills from the platform, so that I can streamline AP workflows without relying on external tools.🎯 Definition of Done (DoD)✔ Business users (Admins) can view and manage all Vendors from a dedicated section in the platform, with support for:<ol><li>List view of all vendors with search, sort, and filter</li><li>Create, Read, Update, Delete (CRUD) operations using Laravel-based backend logic</li><li>Vendor details include</li><li>First name</li><li>Last name</li><li>Email</li><li>Phone</li><li>Job title</li><li>Date of birth</li></ol>✔ Business users can manage Bills through a separate Accounts Payable &gt; Bills section, with:<ol><li>List view of all bills, sortable and filterable by vendor, status, and date</li><li>CRUD operations for one-time</li><li>Each bill supports:</li><li>Line items (manual input)</li><li>PDF generation</li></ol>✔ All actions (vendor creation, bill creation, updates, status changes, etc.) are powered by Pelcro’s CORE API endpoints, which:<ol><li>Serve as the single source of truth</li><li>Are documented and stable for internal and future external use</li><li>Are consumed by the Admin UI as a client of the API</li></ol>✔ This change will impact:<ol><li>UI – Admin-only sections for Vendors and Bills</li><li>API – New versioned CORE endpoints (e.g., <code>/vendors</code>, <code>/bills</code>)</li><li>Backend – Laravel CRUD services for all related operations</li></ol>✔ This solution will include the following limitations:<ol><li>No vendor self-serve access (OpenAPI/SDK not yet exposed)</li><li>No delivery logic, rate automation, or accounting integrations</li><li>No tax calculation or international currency handling</li></ol>Vendors Resource:<ol><li>GET /v1/core/vendors – List vendors</li><li>POST /v1/core/vendors – Create vendor</li><li>GET /v1/core/vendors/{id} – Show vendor</li><li>PUT /v1/core/vendors/{id} – Update vendor</li><li>DELETE /v1/core/vendors/{id} – Delete vendor</li></ol>Bills Resource:<ol><li>GET /v1/core/billing/bills – List bills</li><li>POST /v1/core/billing/bills – Create bill</li><li>GET /v1/core/billing/bills/{id} – Show bill</li><li>POST /v1/core/billing/bills/{id}/finalize – Finalize bill</li><li>POST /v1/core/billing/bills/{id}/mark-as-paid – Mark bill as paid</li></ol>Publisher InterfaceVendors Management:<ol><li>GET /{site_id}/vendors – List vendors</li><li>GET /{site_id}/vendors/create – Create vendor form</li><li>GET /{site_id}/vendors/{vendor_id}/edit – Edit vendor form</li><li>GET /{site_id}/vendors/export – Export vendors</li><li>POST /{site_id}/vendors – Store vendor</li><li>GET /{site_id}/vendors/{vendor_id} – Show vendor</li><li>PUT /{site_id}/vendors/{vendor_id} – Update vendor</li></ol>Bills Management:<ol><li>GET /{site_id}/bills – List bills</li><li>GET /{site_id}/bills/create – Create bill form</li><li>POST /{site_id}/bills – Store bill</li><li>GET /{site_id}/bills/{bill_id} – Show bill</li><li>GET /{site_id}/bills/export – Export bills</li><li>POST /{site_id}/bills/{bill_id}/finalize – Finalize bill</li><li>POST /{site_id}/bills/{bill_id}/mark-as-paid – Mark as paid</li></ol>Events:<ol><li>Bills:</li><li>Bill\Created – When a bill is created</li><li>Bill\Finalized – When a bill is finalized</li><li>Bill\Paid – When a bill is marked as paid</li><li>Vendors:</li><li>Vendor\Created – When a vendor is created</li><li>Vendor\Updated – When a vendor is updated</li><li>Vendor\Deleted – When a vendor is deleted</li></ol>Webhooks:<ol><li>Bill Webhooks:</li><li>BillCreated – Webhook listener for bill creation</li><li>BillFinalized – Webhook listener for bill finalization</li><li>BillPaid – Webhook listener for bill payment</li><li>Vendor Webhooks:</li><li>VendorCreated – Webhook listener for vendor creation</li><li>VendorUpdated – Webhook listener for vendor updates</li><li>VendorDeleted – Webhook listener for vendor deletion</li></ol>

Accounts Payable - Vendors & Bills

<h3>Problem Statement</h3>Currently, when an auto-renewal subscription is cancelled, Pelcro automatically changes the renewal type from Auto-Renewal to Manual Renewal. This behavior causes downstream issues, particularly with fulfillment logic, because cancelled subscriptions are no longer represented accurately based on how they were originally sold and paid for.As a result, eligible customers are excluded from fulfillment lists, even when they are still entitled to receive issues already covered by payment.<h3>Definition of Done (DoD)</h3><ul><li>Renewal type remains unchanged when a subscription is cancelled.</li><li>Cancellation only affects:<ul><li>Subscription status</li><li>Renewal behavior (future billing)</li></ul></li></ul>

Do not change renewal type to manual renewal when a subscription is cancelled

<h2>🔍 Problem Statement</h2>As a publisher or operations admin using Pelcro,I experience that all gift subscriptions are treated as one-time purchases, regardless of the plan’s renewal configuration,which results in inability to offer auto-renewing gift subscriptions and inconsistent renewal behavior compared to standard subscriptions.<h2>💡 User Story</h2>As a publisher or subscription admin,I want gift subscriptions to inherit their renewal behavior from the selected pricing plan,so that one-time and auto-renewing gift subscriptions are supported natively and behave predictably.<h2>🎯 Definition of Done (DoD)</h2>A feature is done when:✔ Given a pricing plan with <code>renewal_type = self-renew</code>, (NOTHING CHANGES)when a gift subscription is created using this plan,then the gift subscription remains one-time and does not auto-renew, matching current behavior.✔ Given a pricing plan with <code>renewal_type = auto-renew</code>,when a gift subscription is created using this plan,then the gift subscription auto-renews according to the plan’s billing cycle using Pelcro’s standard renewal and dunning logic.✔ This change will impact API, specifically subscription creation and renewal logic for gift subscriptions in the backend.✔ This solution will include the following limitations:<ol><li>Existing one-time gift subscriptions are not retroactively converted to auto-renewing</li><li>Renewal behavior is determined only at subscription creation time</li><li>No UI changes are included as part of this feature</li><li>No mixed renewal behavior within a single gift subscription is supported</li></ol>

Allow auto renew gifts

<h3>Problem Statement: </h3>Currently, Pelcro does not provide a Revenue Waterfall Report. Finance teams lack visibility into how booked revenue transitions into recognized revenue over time, including the monthly recognition breakdown. This limits their ability to comply with accounting standards and forecast accurately.

Introduce Revenue Waterfall Accounting Report

Problem Statement Businesses cannot easily see how many subscriptions were scheduled to end in a given period (e.g., a calendar year), how much revenue those subscriptions represented, or what percentage renewed. Existing reports do not solve this because multi-year plans fall outside the annual Subscription Health report. User Story As a business, I want a report showing all subscriptions scheduled to end during a selected period and the percentage that renewed, including a breakdown of manual vs automatic renewals, so I can measure retention and renewal performance. Questions the Report Should Answer For a selected period (e.g., 2025): <ol><li>How many subscriptions were scheduled to end?</li><li>What was the invoice total associated with those subscriptions?</li><li>How many of those subscriptions renewed?</li><li>What is the revenue value of those renewals?</li><li>Of the renewed subscriptions, how many were automatic vs manual?</li></ol> Definition of Done (DoD) <ol><li>Admins can select a date range and view all subscriptions scheduled to end during that period.</li><li>The report displays:</li><li>Total expiring subscriptions</li><li>Invoice value of the expiring cohort</li><li>Renewed subscription count + renewal value</li><li>Renewal rate</li><li>Automatic vs manual renewal breakdown</li><li>Report is visible in the dashboard and can be exported.</li></ol>Example:<ol><li>Period: 2024</li><li>Subscriptions That Will End in the period: 1000 </li><li>Of those 1000 — 90% (900) renewed </li><li>Auto renewed: 85% (800)</li><li>Self renew: 50% (100) </li></ol>

Subscription Expiry & Renewal Cohort Report

Problem StatementCurrently, customers upgrading plans cannot see the exact price difference (including proration) before confirming the change.Although the backend calculates this internally, the OpenAPI response for order summary does not expose this information, leaving the frontend unable to display accurate totals.User Story<blockquote>As a subscriber, I want to see a detailed breakdown of how my upgrade or plan change amount is calculated — including any prorated charges — so that I can make an informed decision before confirming the change.</blockquote>Definition of Done (DoD)<ol><li>Extend Subcription Summary OpenAPI ) to include:</li><li>Total difference charge &gt; <code>change_summary_total</code> (field name should be similar to core API field)</li><li>Ensure returned totals match backend billing calculations used in the actual plan change process.</li><li>UI / SDK</li><li>Update Change Plan modal / component to:</li><li>Display the change difference amount in the order summary section.</li><li>Format amounts consistently with platform pricing (currency, sign).</li><li>Update OpenAPI docs to reflect new response structure.</li><li>Unit and integration tests confirming accuracy for:</li><li>Plan upgrade</li><li>Downgrade</li><li>Mid-cycle changes</li><li>Confirm SDK handles new fields without regression.</li></ol>Affected Components<ol><li>Backend </li><li>Default UI </li><li>Crain UI </li></ol>