Облік льняного магазину в n8n, зібраний у Claude Code за повідомленнями звичайними словами: кожна оплата Stripe і кожне замовлення з сайту — в обліку, PDF-інвойс або кредит-нота з номером без пропусків, а ще SEPA, повернення, спори, три валюти, ранкове зведення й місячне вивантаження для бухгалтера. Звичайні продажі карткою були правильні. Шість речей — ні: ПДВ для двох видів бізнес-клієнтів, повернення, яке Stripe відхиляє через години після «успіху», зведення з «net €0.00», облік, що мовчки зупинявся, поки база магазину не відповідала, і магазин, який показував інший ПДВ, ніж інвойс. Усі шість виправлено.
6 проблем: 4 середні, 2 низькі. Австрійська фірма з німецьким номером ПДВ платила австрійський ПДВ, €33,00 із €198,00, замість зворотного нарахування; латвійська фірма з доставкою до Берліна — німецький ПДВ замість латвійського; повернення, яке Stripe відхилив через дві години, лишалося в обліку як повернене, а клієнт мав кредит-ноту на гроші, яких не отримав; поки база магазину мовчала 12 хвилин, в облік не потрапляло нічого, навіть оплати, не пов'язані з магазином, і ніхто про це не дізнавався; у дні з банківськими переказами ранкове зведення починалося з «net €0.00»; магазин показував 21% ПДВ, а інвойс брав ПДВ країни доставки; на цю різницю вказав сам ШІ, а власник спершу попросив магазин не змінювати. Усі шість виправлено: хибні інвойси скасовано кредит-нотами й виставлено знову, власник дізнається про збій за хвилину, магазин та інвойси рахують однаковий ПДВ. Із 133 перевірок на зданій версії падали 9, на фінальній — жодна. Виплати Stripe у тестовому режимі побачити не вдалося; це та інші межі названо у звіті. Власнику лишено: комісію Stripe за банківські перекази і вхід до бази лише на читання. Одна автоматизація, зібрана один раз: цифри описують цей облік, а не типову картину для таких систем.