1. Why multi-entity is fundamentally different
A single-property hotel treats KSeF as a compliance checkbox: one NIP, one authorisation token, one JPK_V7M cadence, one księgowa. A hotel group with three or more Sp. z o.o. entities running under a corporate holding treats KSeF as an architecture problem. Each Sp. z o.o. is a separate VAT payer with its own NIP, its own KSeF authorisation, its own bank account for split-payment, and its own monthly return; the corporate finance office nonetheless expects one consolidated view for the holding. Every Suite Profit engagement we run for a group starts by drawing the fiscal graph — one node per Sp. z o.o., one edge per intercompany service — because that graph will govern every connector, every batch job and every reconciliation that follows.
2. Per-entity fiscal segregation is non-negotiable
The single biggest architectural mistake we see is groups treating KSeF as a group-level facility. It is not. Every issued invoice is legally attributable to exactly one taxpayer entity, and if your connector allows a group operator to accidentally issue an invoice from Property A's Booking Engine tenant against Property B's NIP, you have created a tax exposure that the Krajowa Administracja Skarbowa will not treat leniently. Suite Profit's Group Fiscal Automation (Poland) module enforces the entity boundary at three levels: the KSeF authorisation token is bound to a single NIP and cannot be shared; the JPK_V7M batching queue is partitioned per Sp. z o.o. so entries cannot cross entities; and the audit log records the authorising signatory per entity, so the corporate finance director can defend every invoice to ownership.
3. JPK_V7M batching under group finance
A corporate finance office typically wants one monthly close cadence across the group, not three or five staggered cadences. That is achievable but requires the batching layer to sit above the entity boundary while the invoices themselves remain segregated. In practice we run a nightly per-Sp.-z-o.o. batch that produces a per-entity JPK_V7M staging file; the group monthly close then aggregates the staging files into a consolidated management view, while each Sp. z o.o. still submits its own return to the Ministerstwo Finansów by the 25th. The corporate CFO reviews a single reconciliation report; the księgowa firm still files three (or five, or seven) returns.
4. KSeF connector strategy: reference implementation
Suite Profit's reference KSeF connector architecture for a group is a hub-and-spoke design. The hub is the corporate finance layer — one Group Fiscal Automation instance bound to the group's Profitroom Suite tenants through the official Profitroom API. Each spoke is a per-Sp.-z-o.o. KSeF binding with its own authorisation token. The Profitroom Reservations feed on each tenant emits reservation data; the connector routes each reservation to the correct spoke based on the property-to-entity mapping the finance director publishes once. The corporate finance office never handles KSeF tokens directly — they are provisioned into a hardware-backed key vault at engagement kickoff and rotated on a policy the księgowa firm signs off on annually.
5. Corporate finance office workflows
The workflows that change most under KSeF are not the invoice-issuance workflows — those become largely automated — but the exception workflows. A group finance office needs a defined process for the three exception types we see repeatedly: a rate-plan mapping error that causes a rate line to appear on the wrong VAT rate, an intercompany service that crosses the entity boundary and must be invoiced Sp.-z-o.o.-to-Sp.-z-o.o., and a KSeF submission failure that requires a manual retry with the księgowa's involvement. Every Suite Profit engagement includes a workflow-authoring session with the corporate finance office to codify these three exception handlers before go-live.
6. Common failure modes at group scale
Four failure modes account for the majority of pain we have seen in the field. First, a shared corporate email address used to receive KSeF confirmation webhooks — one bounce and the entire group loses visibility of issued invoices; use per-entity distribution lists with a corporate archive. Second, a rate plan reused across two Sp. z o.o. entities with the same internal name but different VAT treatment — the moment a rate-plan mapping table stops carrying the entity context, invoices start drifting. Third, a MPP (split-payment) threshold breach on a corporate-event invoice that combines rooms across two entities in the group — this is a legal invoice-splitting requirement, not a nice-to-have. Fourth, a JPK_V7M submission that succeeds at the entity level but conflicts with the group's consolidated management view because of an intercompany reconciliation gap.
7. The 1 August 2026 cutover — what your finance office should already have
Six weeks out from the mandatory-issuance date, a group finance office should have all of the following in place: the fiscal graph document approved by the corporate CFO and the księgowa firm; per-Sp.-z-o.o. KSeF authorisation tokens provisioned in a hardware-backed vault; a rate-plan-to-VAT mapping table under version control with the corporate finance office as sole owner; a group monthly close cadence with a consolidated reconciliation dashboard; the three exception workflows codified and rehearsed; and a documented rollback plan for the first two weeks of live issuance. If any of these are missing, Suite Profit's fiscal practice will run a five-day readiness engagement to close the gap.