PENTESTY · EDITORIAL ANALYSIS · · 4 min read
After an invoicing incident: who can change where a payment goes?
Knowing an invoice does not establish authority to change its receiving account. Review how a request is confirmed, approved and executed.
By Pentesty
The updated statement changes the news context
In its October 1, 2026 update, Fakturownia confirmed data copying through unauthorized access and said the incident involves all accounts, with differences by category and period. In a September 30 statement, Poland’s finance ministry said it had not identified a KSeF compromise. The analysis below proposes a business exercise; it does not describe confirmed payment fraud in this incident.
Test a change from start to finish with fictional data
Use a test supplier and obligation in an authorized environment. Agree on the expected result before starting. Follow the request through to a simulated payment instruction, preserving the separation between the person editing information and the person accepting the change.
- Request: record the channel, claimed identity and intended change without treating those elements as confirmation.
- Verification: confirm through the previously registered contact and record who checked it. A number supplied in the request itself does not meet this criterion.
- Approval: check whether an account lacking the required role can complete the change. Record the expected denial and any authorized exception.
- Execution: compare the approved beneficiary with the destination in the simulated instruction. Check whether later changes require a fresh decision.
Include integrations and work already pending
A change may cross a finance application, supplier directory and external service. Identify which system determines the destination and which integrations can modify it. Rotating a credential requires observing effective permissions afterward, including scheduled jobs. An updated screen does not demonstrate that an older queue has stopped using previous information.
This connects with third-party query and access boundaries. The exercise hypothesis should include an allowed operation and an out-of-scope attempt. Observe the outcome in the component receiving the operation, without using customer information or samples attributed to a data leak.
Deliver a decision about the observed workflow
Record system versions, test accounts, the requested change, expected approval and observed result. The finance owner should understand what needs changing; the technical team should have enough evidence to repeat the check. Also define how to handle requests pending during remediation.
Pentesty’s analysis is that acceptance needs to connect records, authorization and execution. A pentest can assess digital controls within scope, while the company remains responsible for commercial confirmations and financial decisions. Repeat the scenario after changing an integration or procedure, also checking that legitimate payments remain possible.
Frequently asked questions
Does an invoicing incident establish payment fraud?
No. This article uses the statement as context for an exercise. A conclusion about fraud requires evidence of the request, authorization and execution of the particular payment.
Does a correct invoice number confirm the requester’s identity?
It identifies a bill but does not establish authority to modify the beneficiary. Use the approved procedure and a confirmation contact established before the request arrived.
Does changing an integration key complete the review?
Check permissions, pending jobs and the result in the receiving system. Replacing a credential needs to preserve authorized work and remove access that is no longer necessary.
What evidence should we request during a retest?
Request repetition of the change using fictional information, the approval decision and the destination of the simulated instruction. Record limitations and confirm legitimate operation with the finance owner.
Sources and references
Original Pentesty analysis, published October 16, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.