slug: payabli
provider: Payabli
generated_by: planning/capability-mapping/scripts/classify_capabilities.py
model: claude-opus-5
frame:
- Software & Technology
min_confidence: 0.7
capability_model:
  source: https://github.com/vincentmakes/turbo-ea-capabilities
  license: CC-BY-4.0
  attribution: Turbo EA Capabilities by Vincent Verdet — Turbo EA, https://github.com/vincentmakes/turbo-ea-capabilities,
    CC BY 4.0
  notice: NOTICE
edge_count: 5
edges:
- tag: Bill
  spec_file: payabli-bill-api-openapi.yml
  capability_id: BC-200.20
  capability_id_l1: BC-200
  capability_name: Accounts Payable Management
  confidence: 0.85
  evidence: POST /Bill/single/{entry} AddBill — Add bill; POST /Bill/approval/{idBill} SendToApprovalBill
    — Send a bill to approval; GET /Bill/approval/{idBill}/{approved} SetApprovedBill — Approve or disapprove
    a bill; schema BillOutDataVendor
  reason: 'Full vendor-bill lifecycle: create, update, attach documents, route for approval and approve/disapprove,
    with vendor references — this is payables/invoice processing (the vendor''s ''Pay Out'' payables side).
    Maps to Accounts Payable Management; slight residual risk that the buyer frames it as disbursement
    execution rather than AP accounting.'
- tag: Customer
  spec_file: payabli-customer-api-openapi.yml
  capability_id: BC-420.10
  capability_id_l1: BC-420
  capability_name: Customer Data Management
  confidence: 0.8
  evidence: POST /Customer/single/{entry} AddCustomer — Add customer; PUT /Customer/{customerId} UpdateCustomer
    — Update customer record; GET /Customer/link/{customerId}/{transId} LinkCustomerTransaction — Link
    Customer to Transaction
  reason: CRUD over customer/payor master records plus linking a customer to transactions and capturing
    consent opt-in — maintenance of the customer record. Customer Data Management is the best fit; some
    chance the intended reading is billing-account maintenance instead.
- tag: Invoice
  spec_file: payabli-invoice-api-openapi.yml
  capability_id: BC-200.30
  capability_id_l1: BC-200
  capability_name: Accounts Receivable Management
  confidence: 0.75
  evidence: POST /Invoice/{entry} AddInvoice 'Add invoice'; GET /Invoice/send/{idInvoice} 'Send invoice
    via email'; GET /Export/invoicePdf/{idInvoice} 'Export Invoice PDF'
  reason: Full lifecycle of customer invoices — create, send by email, export PDF, list per paypoint/organization
    — which is receivables invoicing. Not subscription-billing specific (no rating/dunning surface here),
    so the cross-industry Accounts Receivable sub-capability is the honest fit.
- tag: User
  spec_file: payabli-user-api-openapi.yml
  capability_id: BC-620.20
  capability_id_l1: BC-620
  capability_name: Identity & Access Management
  confidence: 0.75
  evidence: POST /User AddUser 'Add User to an Organization'; PUT /User/mfa/{userId} 'Enable/disable MFA
    for user in an organization'; POST /User/auth/{provider} 'Authenticate User'; 'Update password for
    User'
  reason: Operations are user account provisioning plus authentication, MFA and password/credential lifecycle
    for organization users — identity and access management, not a payments business capability despite
    the vendor's domain. Title 'Bill User API' is an artefact of tag-splitting and ignored.
- tag: Ocr
  spec_file: payabli-ocr-api-openapi.yml
  capability_id: BC-200.20
  capability_id_l1: BC-200
  capability_name: Accounts Payable Management
  confidence: 0.7
  evidence: POST /Import/ocrDocumentForm/{typeResult} 'Ocr Document Form'; schemas OcrVendorBillingData,
    OcrBillItem, OcrVendor
  reason: Document capture that extracts vendor bill data (OcrVendor, OcrBillItem, OcrVendorBillingData)
    for import — i.e. supplier invoice/bill capture feeding payables processing. Confidence held at 0.7
    because the tag itself is a technique (OCR) and only the schema names ground the payables reading.