Have something to say?

Tell us how we could make the product more useful to you. We URGE you to use the Pelcro Discovery GPT to help structure your thoughts and recommend a feature request that will be quickly digested by our team!

Daily Accounting Report with Totals by Payment Type

Problem Statement The client currently uses the Pelcro Total Report to retrieve accounting information. While the report contains the necessary data, it is not optimized for daily accounting workflows. Their accounting team needs to run the report daily, then manually: Filter or sort transactions by day Group results by title Group further by payment type Calculate totals per payment type This requires manual manipulation of the exported report, making the process time-consuming and error-prone. User Story As an accounting or finance user, I want a daily accounting report that is already grouped and summarized, so that I can quickly reconcile transactions without manual sorting and calculations. The client has provided an example report to illustrate the expected format. The file will be attached to this task for the Pelcro team to review internally to better understand the required report structure and layout. Link:https://docs.google.com/spreadsheets/d/1z6TOhVLFNc12tJLXc38bat98nXbLSYPP/edit?usp=sharing&ouid=107973340733417770971&rtpof=true&sd=true

Sara Habib 8 days ago

Reflect Extended Subscription End Date on Subscription Details Page

Problem Statement Currently, when a subscription’s end date is extended in the Pelcro platform (Admin Dashboard), the new extended date is saved successfully at the system level. However: The updated end date is not reflected on the Subscription Details page. The “Extended” indicator/tag only appears when the extended date is reached. Collaborators must attempt to extend the subscription again to confirm that the previous extension was saved. This creates confusion for internal teams managing subscriptions. User Story As a Pelcro Admin or Collaborator, I want to see the updated subscription end date and extension status after extending a subscription, So that I can confidently confirm the action was saved. Proposed Solution Display the new extended Subscription End Date on the Subscription Details page after a successful extension. Display a clear visual indicator such as: “Extended: [date]” “New End Date: [date]”

Sara Habib 12 days ago

Planned

Recurring bills

Problem 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. Solution 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]. DOD: I can create a vendor subscription using the same configuration flow as AR subscriptions. I can select a vendor when creating the subscription. I can configure a recurring bill plan for the subscription. The system generates recurring bills automatically. I can view the generated bills in Accounts Payable. Bills can be calculated as a fixed recurring amount (e.g. $100 per month). Bills can be calculated dynamically based on shipment quantities using simple rate logic.

Rana Haleem 18 days ago

Planned

Daily Business Health Dashboard

Problem Statement 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?” User Story 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. Feature Summary A read-only Daily Operations Dashboard designed for quick daily check-ins, focused on: Business momentum Payment and checkout health Subscriber activity Trend comparison vs recent historical baselines (e.g. same time last week) The dashboard is visual, graph-driven, and confidence-oriented (not alert-based). Core Metrics (All with graphical trends + “same time last week” reference) Revenue (MTD) – line/area graph Payments (MTD) – successful vs failed Churn (MTD) – count (and rate if available) New Subscribers (Last 5 Days) – daily trend graph Recent New Subscribers – latest sign-ups list Most Active Collaborators – ranked activity list Operational Health Indicators (Passive) Checkout activity present Failed payments within normal range No fraud signals detected (if available) API Requirements (High-Level) Aggregated, cached analytics endpoints for: Revenue, payments, churn, subscriber counts Support time-based comparisons (e.g. same time last week) Read-only, fast, and multi-tenant safe Definition of Done (DoD) Dashboard loads quickly and is accessible from Pelcro admin All metrics are graph-based with historical comparisons Data matches existing Pelcro billing and reporting data No alerts or actions triggered from this dashboard APIs are documented, tested, and reusable across clients Display online vs offline payments top segmentation idea Display breakdown of the top products/plans subscribed to

Rana Haleem 18 days ago

In Progress

Introduce Carrier tips

Problem Statement 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. User Story 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. Scope & Impact Impacted Components: UI, API, Accounting & Reporting Use Case: Print subscriptions only Functional Requirements Tip Entry Subscribers can add or manage a recurring carrier tip during checkout or via subscription management. Tip is optional, fixed-amount, and billed on the same cycle and payment method as the subscription. Admins can enable/disable tips and configure allowed amounts. Billing & Invoicing Tips appear as a separate invoice line item (vendor_tip). Clearly labeled, non-discountable, non-taxable by default. Charged together with the subscription. Accounting Treatment Tips are not revenue and are excluded from MRR/ARR. Recorded as liabilities until paid. AP Conversion (Bills & Vendors) Each subscription is linked to a Vendor (individual driver or carrier company). On successful invoice payment: Pelcro creates AP Bill for the Vendor. Tip is added as a Bill Line Item referencing the source invoice. Payouts Pelcro does not execute payouts. Publishers pay vendors via existing AP workflows and mark bills as paid in Pelcro. Definition of Done Subscribers can add/manage recurring carrier tips. Tips bill correctly and appear separately on invoices. Tips are excluded from revenue metrics. AP Bills are automatically generated per Vendor. Invoice → Bill traceability is available. APIs, docs, and automated tests are updated.

Rana Haleem 18 days ago

Planned

Subscription across multiple sites

🔍 Problem Statement 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. This results in confusing access behavior, fragmented content availability, and reduced perceived subscription value, often leading to support requests or duplicate subscriptions. 💡 User Story 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. 🎯 Definition of Done (DoD) A feature is done when: ✔️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. Acc multiple sites > if subscription attached to product, return all subscriptions related to that site. ✔️ This change will impact API and SDK/ JS part, specifically: Subscription entitlement resolution at the API level Paywall evaluation logic within the Pelcro SDK to recognize cross-site entitlements No change to purchase flows or checkout UI behavior ✔️ This solution will include the following limitations: Applies only to sites under the same Pelcro account Does not extend access across different Pelcro accounts Products configured for a single site will continue to behave as they do today Retroactive application to existing subscriptions is out of scope.

Rana Haleem 18 days ago

In Progress

Enforce 15-Character Minimum for Strong Passwords

✨ Feature Request: Enforce 15-Character Minimum for Strong Passwords 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. User Story 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. Proposed Change Update the existing Strong password enforcement feature to enforce: Minimum password length: 15 characters Maximum password length: 64 characters (passphrase support) Apply enforcement consistently across: Customer sign-up Password reset Password change flows Definition of Done (DoD) Strong password enforcement enforces a 15-character minimum for passwords Maximum supported password length is 64 characters Enforcement applies only to newly created or updated passwords Existing passwords are not invalidated or forced to reset Validation is enforced at API, UI, and SDK levels Clear validation errors are returned when requirements are not met Automated tests are updated or added Security documentation is updated accordingly

Rana Haleem 18 days ago

In Progress

Vendor-Based Fulfillment Segmentation (Platform UI)

🧩 Problem Statement 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 vendor, 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. 👤 User Story As a publisher operations manager, I want to filter lists and fulfillments by vendor, 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. 🏗 Proposed Solution 1️⃣ List Builder Enhancements In List Builder, allow filtering on: vendor (dropdown selector of existing vendors) vendor = null (unassigned addresses) vendor ≠ null (any assigned vendor) Filtering applies at the Address object level. 2️⃣ Platform Fulfillment File Enhancement When generating a fulfillment from the Platform UI: Include Columns: vendor_name delivery_sequence_number 🔌 API Requirements List queries must support filtering by: vendor_id vendor_id = null Fulfillment generation must include: vendor_name delivery_sequence_number Fields must be exposed in fulfillment response payload ✅ Definition of Done (DoD) ✔ 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: Multiple vendors Mixed assigned/unassigned addresses Mixed sequence values 📊 Business Impact Enables operational vendor segmentation directly in Pelcro Reduces manual spreadsheet sorting Supports scalable newspaper distribution workflows Complements delivery sequence feature

Rana Haleem 18 days ago

In Progress

Driver Delivery Sequence Number

🧩 Problem Statement Publishers delivering newspapers via internal drivers (not USPS) require a structured delivery order per address. Pelcro currently has no field to store a delivery sequence number, making it impossible to preserve or manage route order within the platform or during migration. Publishers must manage delivery order externally, creating operational inefficiencies. 👤 User Story As a publisher operations manager, I want to assign a driver delivery sequence number to an address, so that delivery order can be preserved and included in fulfillment exports. As a publisher migrating to Pelcro, I want to import this sequence number via API, so existing driver routes are not disrupted. 🏗 Proposed Solution Add a new field to the Address object: delivery_sequence_number Field Specifications Type: Integer Nullable: Yes Validation: Must be ≥ 1 if set No enforced uniqueness 🔌 API Requirements Field available in: POST /addresses PUT /addresses/{id} GET /addresses/{id} Import / migration endpoints Included in API responses Fully documented in API schema 🖥 Admin UI Requirements Add numeric input field in Address Edit View Label: Driver Delivery Sequence Validation: Integer ≥ 1 Editable from platform 📦 Fulfillment Export Update Add a new column in print fulfillment exports: delivery_sequence_number No change to default export sorting logic. If value is null, export cell remains empty. ✅ Definition of Done (DoD) ✔ Address object includes delivery_sequence_number ✔ Editable via Admin UI ✔ Create/update via Core API ✔ Supported in migration imports ✔ Visible as a column in fulfillment export ✔ API documentation updated ✔ QA validated on staging

Rana Haleem 18 days ago

Paid-Only Newsletter Controls for Subscribers

I’d like to submit a feature request regarding newsletter management and subscription flows. Currently, the default UI allows newsletter selection at registration and enables users to update their newsletter preferences regardless of whether they are paying subscribers. While this works well for general newsletters, it creates limitations when trying to manage exclusive, paid-only newsletter content. We would like the ability to restrict certain newsletters so they are available only to active paying subscribers. For example: Automatically subscribe new paid subscribers to an exclusive e-edition newsletter. Allow access to select additional premium newsletters, but only while the subscription is active. Prevent non-paying users from viewing or subscribing to these paid-only newsletters. Support assigning more than one exclusive paid newsletter to eligible subscribers. This would create a more consistent and controlled newsletter flow for paid products and help reinforce the value of subscription tiers. Ideally, this could be handled through: Newsletter-level access controls tied to subscription plans. Automated enrollment rules triggered upon successful subscription. Dynamic removal of access if a subscription lapses. Webhooks or Zapier triggers to update ESP since we don’t integrate with any ESP directly

Caitlin Havlak 19 days ago

Expand the size of the Footer Memo or alternate field and allow basic html/markdown

The footer memo is currently limited to 250 characters. We would like to reiterate some of our Terms of Service and the ideal place to include this is either in Invoice footer memo Another option might be to allow for an additional memo field that would appear below the invoice footer memo and above the Privacy Policy and Terms of Service links. The current memo fields also do not allow for any kind of basic html to be included (perhaps through Markdown). Specifically, bold, italics, bullets, numbered lists, line breaks etc. Currently it is just one long line of text. See example of how it appears currently. Certain information is blurred on purpose.

Manish Patel 23 days ago

In Progress

Upgrade tickets list UI

Problem Statement Pelcro’s current Tickets list view lacks key operational capabilities required by support and operations teams. Tickets cannot be assigned to collaborators (Pelcro admin users), cannot be efficiently sorted or filtered by operational metadata, and do not surface vendor information that is already being implicitly determined by the AI Shipping Agent via the customer’s address. This results in: Manual coordination outside the platform to assign ownership Inefficient ticket triage and prioritization Lack of visibility into which vendor is associated with a customer issue Reduced usefulness of the Tickets list for high-volume support workflows User Stories 🎧 Support / Ops User As a Pelcro admin, I want to assign a ticket to a collaborator, so ownership and accountability are clear. As a Pelcro admin, I want to sort tickets by created date and last updated date, so I can prioritize work efficiently. As a Pelcro admin, I want to see the Vendor ID and Vendor name directly in the Tickets list, so I immediately understand which vendor is impacted. As a Pelcro admin, I want the Vendor name to be clickable, so I can quickly navigate to the vendor record. Anyone can add a ticket/ assign a ticket

Rana Haleem 25 days ago

Planned

Vendors Payment Batch & ACH NACHA Export

Problem Statement When multiple vendor are owed money, finance teams must manually determine who should be paid, how much to pay each vendor, and then prepare bank files externally. This process is error-prone, slow, and difficult to audit. User Story As a finance user, I want to create a payment batch that automatically determines which vendors should be paid and generates an ACH export, so I can pay multiple vendors safely and efficiently. Scope / Behavior Payment Batch Creation From Accounts Payable, users can create a Payment Batch. When creating a batch, the system: Identifies all vendors with: Outstanding Balance < 0</p> Valid payout method (e.g., ACH enabled) Computes the payable amount per vendor using net AR/AP Excludes vendors with zero or positive balances Payment Snapshot (Implicit) For each vendor included, the system creates a frozen payment snapshot containing: Vendor ID Payable amount Referenced AR invoice IDs Referenced AP bill IDs Timestamp Definition of Done (DoD) ✔ Batch automatically selects payable vendors based on net balance ✔ Payable amounts are frozen at batch creation ✔ Batch review screen displays all included vendors and amounts ✔ ACH NACHA export file is generated successfully ✔ Exported payments cannot be duplicated in another batch

Rana Haleem 25 days ago

In Progress

Vendors ACH Entry (NACHA compliance)

Problem Statement 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. User Story 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. Scope / Behavior Vendor Payout Details Extend Vendor records to support ACH payout configuration. Stored fields (example for ACH): Account holder name Bank name Routing / transit number Account number (securely stored / tokenized) Account type (Checking / Savings) Currency Country Payout method status (Enabled / Disabled / Invalid) Vendor internal identifier (Used as NACHA Individual Identification Number/ System-generated (no manual input)) Transaction type: Credit only (vendor payouts) 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) The ACH entry form should live on the Vendor create/edit page, under Personal Settings → Financial Settings. "ACH Ready / Not Ready" indicator should be surfaced in vendor list/ vendor profile. 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, Definition of Done (DoD) ✔ Vendor records support storing ACH payout details ✔ Sensitive banking data is securely stored and masked ✔ System can determine if a vendor is ACH-payable ✔ Vendors without valid ACH info are excluded from payment batches ✔ ACH details are referenced (not duplicated) in payment batches and exports

Rana Haleem 25 days ago