Payables & Contract Intake Workflow

Read incoming invoices and contracts, code them, and book them.

Coming in Q3. This page describes the planned workflow; it is not available yet. Talk to us about the design-partner program if your payables inbox is the bottleneck.

Billing sends money out to your members. Payables is the other direction: the O&M invoice from the contractor, the grid fee from the utility, the inverter warranty, the lease amendment, the signed PPA. They arrive by email, in a shared drive, as a photo from the field. Someone opens each one, works out which project and which account it belongs to, types it into the accounting system, and files the original somewhere it can be found at audit.

Gridline runs that as a workflow: the document is ingested, the fields are extracted with confidence scores, the coding is proposed from your own history, a human approves, and the booking is created in your accounting system with the source document attached.

Inputs

Incoming documents - supplier invoices, credit notes, contracts, amendments, delivery notes
Intake channels - a monitored mailbox, a watched folder, or direct upload
Chart of accounts - your account, cost centre, and tax code structure
Project and vendor register - so a document can be tied to the right project and counterparty
Coding rules - how this vendor, this document type, or this project is normally coded
Approval policy - who approves what, and above which amount

Controls

Duplicate detection

The same invoice arriving twice, forwarded by two people, or re-sent as a reminder is matched on vendor, number, date, and amount before anything is booked.

Confidence threshold

Low-confidence fields are flagged for review rather than guessed. Totals, tax, dates, and vendor identity are checked, not assumed.

Arithmetic checks

Line items must sum to the stated subtotal, tax must match the applied rate, and the total must close. A document that does not add up stops for a human.

Approval before booking

Booking writes into your accounting system, so it sits behind an approval gate bound to the exact reviewed data. Nothing posts because a document arrived.

Contract terms are read, not signed

For contracts, Gridline extracts parties, dates, renewal and notice terms, and value, then files them against the project. It does not execute or agree to anything.

Pipeline

The same six stages the rest of the platform runs on:

1. Ingest

A document arrives by monitored mailbox, watched folder, or upload. The original is stored immutably and the sender, subject, and arrival time are captured with it.

invoice.pdf stored → linked to intake event

2. Extract

Vendor, document number, dates, currency, line items, tax, and totals are pulled with confidence scores. For contracts: parties, term, renewal and notice periods, and contract value.

invoice.pdf → parsed_document.json (with confidence scores)

3. Allocate

The document is coded: project, cost centre, account, tax code, and where relevant a split across several projects. Proposals come from your history with that vendor and document type, and every proposal is editable.

parsed_document.json + coding rules → coding.json

4. Generate

A booking proposal is assembled: the posting lines, the totals, the attachments, and the reason for each coding decision, ready for a human to read in one screen.

coding.json → booking_proposal.json

5. Sync

On approval, the booking is created in your accounting system with the source document attached, so the entry and its evidence never separate.

booking_proposal.json → booking created → booking_id

6. Deliver

The originator gets confirmation, the document is filed against the project and vendor, and the run’s evidence chain records who approved what and when.

Run status: complete → filed → audit log written

Artifacts

invoice.pdf or contract.pdf - the original, stored immutably
intake_event - channel, sender, subject, arrival timestamp
parsed_document.json - extracted fields with confidence scores
coding.json - project, cost centre, account, tax code, and splits
booking_proposal.json - the posting lines a human approved
booking_id - the reference in your accounting system
approval_record - approver, timestamp, and hash of the reviewed data
duplicate_check - what it was matched against, and why it passed

What changes

Before: documents sit in an inbox until someone has time. Coding lives in one person’s head. The same invoice gets paid twice a few times a year. At audit, finding the original behind a booking means searching email.

After: every document is captured on arrival, coded consistently, approved deliberately, and booked with its source attached. The evidence chain answers “why is this booked here” without anyone reconstructing it from memory.

Roadmap position

Payables and contract intake is planned for Q3, alongside interconnection and project finance. It reuses what already runs in production: document extraction with confidence scores, approval gates bound to reviewed data, and accounting connections that are already used to create invoices in the billing workflows.

Talk to us about the design-partner program →