Skip to main content

Frequently asked questions

Technical FAQ

Answers to the questions buyers and their technical teams ask during evaluation. All answers are derived from the actual codebase, not from marketing copy.

Contracts & billing

All three contract types are live. Dynamic (spot-indexed) contracts are billed on your actual quarter-hourly usage where P4 data is available, with a profile-weighted approximation otherwise; the EPEX spot-price pipeline caches 24-hour EUR/MWh rates from EnergyZero (with ENTSO-E as fallback). Shift usage to cheap hours and pay less.

What this means for you: you can launch and operate under all three contract types - fixed, variable, and dynamic - from day one.

SEPA Direct Debit batches are generated as ISO 20022 pain.008.003.02 XML files. The batch export service runs on a configurable monthly cron, validates mandate FRST/RCUR sequence types automatically, and writes the Pain.008 file to the configured storage backend (local disk, S3-compatible, or Azure Blob). Delivery to the bank is a manual upload step, there is no direct bank API connection. Batch re-export and supersession are available via console commands for failure recovery.

EDSN market integration

The platform covers the full SME and residential supply lifecycle:

Message Purpose
C06Supply suspension notification
SWITCHLVCCP switch flow
C_ARMAnnual meter read request
E0AMeetdata: meter read delivery
E_MROn-demand meter read request
New connectionrequestNewConnection flow

CVB weekly upload and BAR (Balance Accounting Report) are referenced in the operational runbooks but the outbound file generation for these is not yet confirmed in production code. TenneT e-MIPS load profiles (E1A/E1B/E4A) are handled by the simulation layer in demo/dev.

Yes, this is the default. Every outbound EDSN market message is routed through the platform's integration layer, which answers from a built-in simulator when no live market connection is configured, returning realistic synthetic responses. Staff training, customer demos, and the full supply lifecycle can be run without EDSN registration. Going live is a matter of pointing that one integration layer at the real market after EDSN qualification is complete, not an application code change.

Balance responsibility (BRP) is built as a replaceable component with a working simulation behind it, so the platform runs the process end to end today. The live connection to TenneT is not yet built.

This is consistent with how new market entrants typically operate: during the first one to two years it is common practice to outsource BRP to an existing licensed Balancing Group. The platform is designed so that a real BRP adapter can be plugged in without structural changes when needed.

The platform never handles EDSN wire format itself. Message envelopes, signing and schema versions all live in the integration layer, which passes the platform plain, versionless data. A protocol change, such as a new schema namespace or an extra mandatory field, is absorbed there and reaches neither billing, the interface, nor your accounting package. Keeping up with EDSN protocol changes is part of the platform subscription.

Security & GDPR

A defence-in-depth stack is applied at the framework layer and cannot be bypassed by application code:

bcrypt passwords
All passwords hashed with PASSWORD_BCRYPT, no MD5, no SHA1.
Login rate limiting
Exponential lockout per username + per IP via LoginThrottleService. Brute-force attacks are blocked automatically.
CSRF protection
Yii2 CSRF tokens on all POST actions. The meta tag is injected globally in the layout, no per-form opt-in required.
Session cookies
httpOnly, Secure (non-dev), SameSite=Lax. Lax chosen to preserve sessions across OAuth callbacks (Exact Online, Twinfield).
Security headers
X-Frame-Options: DENY, X-Content-Type-Options: nosniff and an enforced Content-Security-Policy, applied to every request across all three applications: the customer portal, the back office and the API.
At-rest encryption
Sensitive evidence (vulnerable-consumer status) encrypted with AES-256-CBC. OAuth2 tokens encrypted via Yii2 encryptByKey().
Role-based access
Yii2 RBAC enforced via AccessControl behavior on every controller. No route is accessible without the required role assignment.

Recommended additions before production launch (not yet implemented): composer audit in CI for dependency vulnerability scanning, and a CSP report-only endpoint for violation monitoring.

Both are implemented as first-class flows. Customers can submit a deletion request or request a full data export from the customer portal. The platform anonymises all PII fields on approval (Article 17) and generates a structured JSON export of the full account record (Article 20). A dedicated staff view in the backend processes and audits these requests.

Current gaps: automated retention-window deletion (accounts are deleted on staff approval, not by a time-based cron) and timestamped marketing consent audit trails (opt-in status is stored as a model flag, not a log). Both are on the backlog.

Not currently. Pinuno is a product-stage company and has not yet completed a formal third-party security audit. The security controls described above are implemented at the code level and can be independently verified. Buyers with a hard certification requirement should factor this into their procurement timeline, a readiness assessment typically takes 3–6 months before audit.

Platform & deployment

No cloud-provider lock-in. The platform runs identically on Docker Compose (single server), self-managed Kubernetes, or any managed K8s service (AKS, GKE, EKS). The Helm chart and Dockerfile are included in the repository. A buyer who holds the source code and the Helm chart can operate the platform fully independently, no Pinuno-controlled services are in the runtime path.

The one dependency tied to the current operator is reCAPTCHA Enterprise (a GCP project). Replacing it with an alternative (hCaptcha, Cloudflare Turnstile) requires changing one validator class and one frontend widget component.

Every infrastructure component is selectable at deploy time via environment variable, no code branching involved:

ComponentOpen-source optionMicrosoft option
SSO / identityKeycloakAzure Active Directory
Object storageMinIO (S3-compatible)Azure Blob Storage
MailerSMTP (any provider)Microsoft Graph (Microsoft 365)
Team alertsMattermostMicrosoft Teams
ERP / accountingERPNextExact Online, Twinfield, AFAS

Switching from one option to another requires changing environment variables and redeploying, the application code is identical in both configurations.

The whole codebase passes PHPStan at level 6, with no suppression file hiding older code behind it. A handful of known findings remain and the build fails on any new one, so the number can only go down.

The PHP 8.2 / MySQL 8.0 stack runs against a matrix of PHP 8.1, 8.2, and 8.3 in CI. Test coverage targets are documented in the DoD; unit and integration test suites are included in the repository.

ERP & accounting integrations

Four systems are supported out of the box, and all four implement the same interface. You choose the package per connection in the back office, so moving to a different one, or running two side by side during a migration, needs no integration work:

System Auth Account sync Invoice sync Payment pull
Exact Online OAuth2 + refresh
Twinfield OAuth2 + refresh
ERPNext API key
AFAS REST token

Moneybird and UNIT4 are not currently supported. Exact Online and Twinfield OAuth2 tokens are encrypted at rest and refresh automatically.

Token refresh runs automatically in the background. If a refresh token is revoked (for example, after a password change in the ERP system), the integration status changes to "disconnected" in the backend integrations dashboard. A staff member with the relevant role re-connects by clicking the OAuth "Connect" button, no developer involvement is required.

Commercial

Enterprise utility platforms, MECOMS 365 (built on Microsoft Dynamics 365) and BE-terna, are designed for established utilities with hundreds of thousands of customers and six-figure annual software budgets. They are not a realistic option for a company going through its first ACM licence application.

General-purpose billing platforms like MaxBill serve the mid-market internationally but do not include Dutch market specifics (EDSN messaging, SEPA pain.008, Energiewet contract types) out of the box, that is a custom integration project on top of the subscription cost.

Energie Software is built specifically for new-entrant Dutch energy labels. It includes EDSN simulation from day one, SEPA Direct Debit batch export, the full supply lifecycle, and four ERP connectors with no additional integration project required. For a label in the 0–10,000 customer range, the total cost of ownership over three years is a fraction of any enterprise alternative.

No. Pricing is discussed directly and is structured around where you are in your market entry process, a label in ACM registration has different needs from one that is already live with 2,000 customers. Contact us to start a conversation.

Still have questions?

If your question isn't covered above, get in touch. We can arrange a technical deep-dive with a developer walkthrough of the codebase.