How to test AI bookkeeping in Poland: five checks for a JDG

To test AI bookkeeping for a Polish sole trader, or JDG, use five situations: an ordinary invoice, the same invoice received twice, a partial payment, an expense that needs explanation and a correcting invoice. Write down the expected result, compare the software output and check how to fix a mistake. Reading the total correctly does not establish that the accounting is correct.

This is a practical evaluation method for a business operating in Poland. It is not a software ranking or a measured accuracy test of Norman. The example amounts are invented solely to explain the relationship between an invoice and its payments.

What are you testing when a product says AI bookkeeping?

The label can cover document extraction, suggested categories, bank matching or answers about company records. Ask to see the complete journey: document, transaction, register, report and any submission. Note which steps the software performs and which require your action.

Here, AI-first describes a workflow that begins with a question or document and prepares the next steps for you. It is not a certificate of accounting accuracy. The useful questions are whether you can trace an answer to its source, identify missing information and change a suggestion.

Check that the workflow fits your business. A Polish JDG and a sp. z o.o. should not receive identical accounting instructions simply because they upload the same invoice. For a JDG, confirm the income tax method, VAT status and applicable records. If you are still choosing a legal form, read the comparison of a JDG and a sp. z o.o..

How should you prepare the sample?

Choose documents from a period that has already been checked. For an ambiguous expense, establish the correct treatment with your accountant before testing. Otherwise, you may be judging one unverified AI answer against another.

Agree on a test method that will not book a closed period again. Use a demonstration environment, sample documents or a guided walkthrough. Do not issue fictional invoices in production KSeF. If the application has no isolated test mode, request a demonstration instead of reimporting historical records into an active business account.

For each case, record the source, invoice reference, expected amount, payment status and reviewer. Include the date or software version. A result from several months ago may no longer describe the current product. Keep the same inputs when comparing providers so that differences in the samples do not distort your conclusion.

Test 1: do the invoice fields match the document?

Start with a clear PLN invoice for a typical business purchase. Compare the supplier, NIP tax identifier, invoice number, dates, currency and net, VAT and gross amounts. Check each line separately if different VAT rates appear. A correct total can still conceal fields assigned to the wrong line.

Open the source beside the extracted fields. Check that the sale date has not been replaced by the issue date, or the amount payable by the net amount. Then inspect the proposed category and the record receiving the transaction. Text extraction alone does not establish the correct tax treatment.

During the demonstration, change one field and check the linked transaction. If a report still contains the previous amount, note exactly where the mismatch occurs. A saved confirmation is not enough if another part of the workflow continues using old data.

Test 2: what happens to a KSeF invoice and its PDF copy?

Ask to see one invoice arriving through KSeF and again as a supplier PDF. Use the same invoice, not two similar documents with identical totals. The expected outcome is one economic transaction whose sources remain identifiable.

The Polish Ministry of Finance describes structured invoices as XML documents. They do not require image extraction. You should still check how the software handles the additional file, shows the relationship and prevents a second accounting entry.

Record the number and total value of transactions before and after adding the second source. Two stored files are not necessarily a problem. Counting one purchase twice is a problem, as is merging two genuinely different invoices just because their amounts match.

Test 3: does a partial payment stay partial?

Use this control example: an invoice totals PLN 1,230 and its linked payment is PLN 600. Assuming no other payments, offsets or corrections, PLN 630 remains. You should be able to reproduce that calculation and open the specific payment.

Check that the invoice has not become fully paid merely because the counterparty and part of the transfer reference match. Then demonstrate a second payment of PLN 630. After it is correctly linked, the remaining balance should be zero.

This tests settlement tracking, not when income arises or VAT becomes deductible. A paid label does not establish a tax recognition date. Add separate cases for batch payments, foreign currencies and fees, where matching a single amount is insufficient.

Test 4: does the software expose missing context?

Choose a document that does not clearly establish the business purpose, such as a subscription also used privately. Do not invent a deductible percentage for the demonstration. Check whether you can identify and supply the information needed to make the decision.

Ask: “What supports this category, and what information is still missing?” A useful answer points to the document and specific gaps. Confidence without a source is not enough. If it cites a tax rule, open the official source and check whether it applies to your circumstances.

Declining to make an automatic decision can be the correct result. Check whether the unresolved expense is easy to find, who needs to explain it and whether the suggestion can be reviewed again after adding context. Silence from the software does not mean the tax question is settled.

Test 5: can you trace a correction to the original?

Use an existing invoice and its correcting invoice, known in Polish as a faktura korygująca. Check that both remain visible, their relationship is clear and the change in value can be verified. If the relationship is uncertain, you should be able to resolve it without losing the history.

The Ministry of Finance explains that an invoice issued in KSeF cannot be edited or deleted. Errors are addressed through a correcting invoice. Changing a local accounting category is a different action from changing an issued document.

Do not assume every correction belongs to the original invoice period. This demonstration tests traceability; confirm the correct accounting period for the particular reason behind the correction. You need a way to inspect the result before closing the reporting period.

Where can you start in Norman?

Start with the sample receipt on the Documents page. The expenses and documents guide explains where to compare extracted fields and review the associated transaction and category. Use that walkthrough before bringing in actual business records.

Do not assume marking a transaction completed is a gate that prevents earlier register entries. Norman documents that a transaction may already enter KPiR and JPK_V7 before this review marker is applied. Inspect the register as well as the task status.

The Norman AI bookkeeping page describes the division of work between the application and the user. In your review, keep report preparation, submission approval, receipt confirmation and payment separate. A submitted report does not prove the corresponding tax has been paid.

How should you decide after the five tests?

For each case, record one of three outcomes: expected result, correction needed or unable to verify. For a mismatch, explain its consequence and the repair process. Do not turn five successful cases into an overall accuracy percentage. The sample is small and deliberately selected.

Shortlist software whose results you can understand and whose incorrect suggestions you can control. Before switching, agree with your current accountant on the cutover date, records to transfer and review of the first period. If you cannot trace an amount or identify an unresolved exception, resolve that issue before changing your bookkeeping workflow.