tripletex-book-inbox-voucher

Tripletex Book Inbox Voucher

Overview

Use this skill to book incoming Tripletex vouchers after validating the Tripletex fields against the attached PDF/invoice/receipt. The goal is a correctly posted voucher with supplier, invoice fields, cost account, VAT code, payment, and booking setting aligned with the source document and known company rules.

Company-, supplier-, and account/VAT-specific facts live in local knowledge/ files referenced by relative path; read knowledge/README.md for source priority before acting.

Guardrails

• Use the in-app Browser when working from an open Tripletex tab.
• Confirm the visible company before booking.
• Treat Opprett, Bokfør nå, and voucher posting as accounting side effects.
• Only book autonomously when the user has granted autonomy for the specific supplier/workflow and evidence is strong enough.
• Stop and ask if supplier, amount, date, currency, VAT treatment, cost account, or payment cannot be verified.
• Do not book if invoice number, supplier, currency, or any amount has not been verified 100% against the visible PDF/image attachment.
• Before booking, check for duplicate invoice/receipt rows in Bilagsmottak; merge duplicates first when appropriate.
• After each real voucher workflow, update this skill if the reusable procedure changed. Update local knowledge/ files when the learning is supplier-specific, account/VAT-specific, or historical.

Core Rule: Select Supplier First

When opening a voucher, choose the correct supplier/leverandør before filling or judging the remaining fields. Tripletex often remembers settings and previous values from the supplier and may auto-populate or improve:

• Currency.
• Payment details.
• Supplier bank account.
• Payment reference.
• Cost account or VAT suggestions.

After selecting the supplier, re-read the voucher fields. Do not rely on the pre-supplier state when deciding what is missing.

Required Attachment Validation

The PDF/image attachment is the source of truth. Before every Opprett, compare the Tripletex values against the visible physical attachment, not only the inbox row, email subject, filename, or Tripletex parser result.

• Supplier legal name and supplier identity.
• Invoice/receipt number (Fakturanummer). This must match exactly. If the attachment contains both invoice and receipt references, identify which number should be used in Tripletex or ask the user.
• Invoice date.
• Due/payment date.
• Currency.
• Every amount used in the posting: total, line/order amounts, VAT basis, VAT amount, paid amount, and NOK bank/payment amount when applicable.
• VAT basis/rate/amount or explicit no-VAT/reverse-charge treatment.
• Payment evidence and payment date when the document is already paid.

If the PDF/image is too unclear to verify invoice number, supplier, currency, or amounts with 100% confidence, stop and ask.

For foreign-currency invoices already paid from a NOK bank account, use the actual bank transaction date and NOK amount for the payment. Do not rely only on Tripletex's calculated NOK amount from the invoice date. When the payment NOK amount differs from the invoice posting NOK amount, Tripletex may automatically post currency gain/loss; verify this after Opprett.

Tripletex may recalculate Beløp NOK when Betalingsdato is changed on a foreign-currency voucher. Set or verify the payment date first, then re-check and, when the field is editable, re-enter the actual bank NOK amount before posting.

If Tripletex blocks posting with Regnskapet er låst for mva-posteringer i perioden, do not change invoice date/bilagsdato or VAT code merely to get past validation. Treat it as a locked-period issue: keep the invoice date and VAT treatment aligned with the attachment and known rules, ask the user to unlock/open the affected VAT period or approve another accountant-backed treatment, then retry.

Booking Mode

Use Enkel føring as the default for simple receipts and invoices that can be booked correctly with one cost line, one VAT treatment, and straightforward payment information.

Use Detaljert føring when the attachment, supplier, Tripletex behavior, payment handling, multiple lines, foreign-currency treatment, or a learned supplier-specific rule requires more detailed registration. If it is not clear whether Enkel føring is sufficient, ask before posting.

Adding PDFs To Bilagsmottak

When a PDF has been downloaded or generated locally and must be added to Tripletex, prefer sending it as an attachment to the correct e-bilag address through the email connector instead of using Tripletex's web Last opp file picker. This is usually more reliable than browser/OS file upload controls and leaves an auditable sent-email message id.

• The active company's e-bilag address is recorded in knowledge/companies.md; resolve it there per company. Do not hardcode an address.
• Verify the PDF locally before sending: text extraction, page count, and visual render when layout matters.
• Use a concise subject that identifies supplier, invoice/order number, period, and company.
• After sending, record the sent message id and PDF path in knowledge/gmail-receipt-sources.md.
• Refresh or wait for Bilagsmottak import, then verify the imported row, page count, supplier, invoice number, date, currency, and amounts before booking.
• Use Tripletex web Last opp only as a fallback when email/e-bilag delivery is unavailable, the user explicitly asks for web upload, or an immediate in-page upload is materially safer. If web upload creates duplicate rows, verify which row contains the complete PDF and delete only the confirmed duplicate before booking.
• If the task is to add a formal invoice to an existing generated email-evidence PDF, prefer creating one combined local PDF with the formal invoice first and the generated evidence after it, then send that combined PDF to e-bilag. This avoids merge-direction mistakes in Tripletex. Delete or merge the old generated-only row only after verifying the combined row has imported correctly.

Workflow

1. Read the inbox row and identify supplier, amount, date, currency, and suggested registration mode.
2. Check whether the row is a duplicate invoice/receipt pair with another row. Use the duplicate-merge skill when needed.
3. Choose booking mode. Default to Enkel føring unless there is a concrete reason to use Detaljert føring.
4. Open the registration page.
5. Select the correct supplier first.
6. Re-read all fields after supplier selection/autofill.
7. Verify invoice number, supplier, currency, dates, and every amount 100% against the PDF/image attachment.
8. Set cost account and VAT code using the rules in knowledge/accounts-and-vat.md. When VAT treatment is uncertain and the top-menu Assistent offers an in-app accounting help panel, use it as an additional control source before asking the user; record the reusable result in knowledge/accounts-and-vat.md. Close the Assistent panel after use because it overlays the voucher fields needed for final review and booking.
9. Set payment method/date/amount using known bank or receipt evidence.
10. Ensure Bokfør nå is intentionally set or unset.
11. Click Opprett only when the workflow is authorized and all checks pass.
12. Verify the result, record voucher number when visible, and check any automatic currency gain/loss posting when foreign currency was paid in NOK.

Reporting

For each booked voucher, report:

• Supplier.
• Invoice number.
• Invoice date and due/payment date.
• Amount/currency.
• Cost account.
• VAT code.
• Payment method/date/amount.
• Resulting voucher number if visible.

Continuous Improvement

At the end of each workflow:

• Add reusable procedural corrections here.
• Add supplier/account/VAT facts to local knowledge files.
• Add supplier-specific exceptions and detailed-booking rules as they are learned through on-the-job training.
• Keep this skill procedural; do not turn it into a long log of every voucher.