Working with documents

Documents are the foundation of everything. The better your uploads, the better the analysis.

RFP documents

Click Upload RFP in the sidebar workflow to open the RFP documents view. Upload everything that's relevant:

• The main RFP document
• Technical specifications
• Contract terms and conditions
• Evaluation methodology
• Appendices and annexes
• Standard forms and templates

The more complete your RFP upload, the more thorough the analysis. If the AI doesn't know about a requirement, it can't check whether the vendor meets it.

Once all RFP documents are parsed, the sidebar shows a green checkmark next to "Upload RFP" and the Suggested next banner updates to guide you to the next step.

Bid documents

For each vendor, add a bid using the + button in the Bids section of the sidebar. Enter the vendor's name, then click the bid to open its document upload view. Upload their submission:

• The main proposal
• Technical response
• Financial offer
• CVs of proposed team members
• Certificates, licenses, references
• Any other supporting documents

A common mistake

Make sure you upload RFP documents to the Upload RFP view and bid documents to the bid's document view. Mixing these up means the AI treats requirements as a vendor's response (or vice versa), and the results won't make sense.

Uploading files

Drag files onto the upload area or click to browse. You can upload multiple files at once.

Supported formats

File size

Files up to 100MB each. If you have something larger, try splitting it or removing unnecessary pages (cover sheets, blank pages, large images that aren't relevant).

Parsing

After upload, each file goes through parsing - the system converts it from a visual format (like PDF) into structured text the AI can actually read.

You'll see a status next to each file:

When parsing fails

The most common reasons:

• Password-protected files - remove the password and re-upload
• Corrupted files - try re-exporting from the source application
• Very poor scans - the text recognition can't read blurry or faded text
• Unsupported format - check the supported formats table above

You can retry parsing for any failed file. If it keeps failing, try converting the file to a different format (e.g., Word to PDF) and re-uploading.

Signed badge

When you upload a digitally signed file (.edoc ASiC-E containers, or PDFs with embedded ETSI CAdES / Adobe PKCS7 signatures), the document view shows a signature panel summarizing what was found.

What the panel shows

• Header — 1 digital signature or N digital signatures. The number reflects how many signatures were detected inside the container, not the number of signers in any external sense.
• Status line — All signatures are cryptographically valid (green) or Some signatures could not be verified — review the details below (amber).
• Per-signer details — for every signature: signer name (CN from the certificate), personal code (serialNumber from the certificate, when present), the signing time recorded in the signature, and the signature format (ASiC-E (XAdES) for .edoc, or the relevant PDF format).
• Per-signer status — each signer row carries a green check (valid) or an amber Invalid badge if that specific signature failed verification.

If signature inspection itself fails (corrupted container, unreadable signature XML), the panel shows a red Signature check failed block with the underlying error instead of signer details.

What "valid" means here

For .edoc archives, "valid" means the signature passed cryptographic integrity verification: the canonicalized SignedInfo XML matches the signed bytes, and the SignatureValue verifies against the embedded X.509 certificate's public key using the declared digest (SHA-256/384/512, RSA or ECDSA).

It does not mean:

• The certificate chain has been validated against eParaksts or any other trust anchor
• The signing certificate was checked against revocation lists at signing time
• The referenced data digests inside the signature have been cross-checked against the archive's payload bytes

Treat the badge as a strong "this signature is internally consistent and the signer's certificate matches the signed bytes" signal, not as full eIDAS-grade trust validation. For legally binding verification, continue to use eParaksts or your usual qualified validator.

Use in analysis

The signature panel is a UI surface for your own review. Signature metadata (signer, signing time) is not currently fed into the AI analysis as evidence — the AI works from the parsed document content, regardless of whether the file was signed.

Unsigned .edoc files

If an .edoc archive contains no signature XML (none of the META-INF/edoc-signatures-*.xml entries the platform looks for), the signature panel is simply not shown. The archive contents are still extracted and parsed for analysis as usual.

Replacing documents

If a vendor sends an updated proposal, or you realize you uploaded the wrong version of a specification:

1. Upload the new version
2. Wait for it to parse
3. Remove the old version if you don't need it
4. Re-run the analysis to get updated results

Note that re-running analysis costs additional credits. See refining analysis for more on when this makes sense.

Best practices

Include everything relevant

The AI can only check requirements it knows about. If your RFP has technical specifications in a separate annex, upload that annex. If there's an evaluation methodology document, include it. The more complete the picture, the more thorough the check.

Skip what's not relevant

Don't upload 50 pages of general procurement legislation that applies to every procurement. The AI will dutifully read it all, use your credits, and clutter the analysis with generic observations. Focus on documents specific to this procurement.

Name vendors clearly

When you create a bid, use the actual vendor name. You'll see this in comparisons, exports, and throughout the interface. "SIA TechnoGroup" is better than "Bid 3".

File format tips

Best results: Native digital documents (PDFs created from Word, not scanned). The text is clean and structured, and parsing is fast and accurate.

Good results: Clear scans with readable text. Modern OCR handles these well, but complex tables and small fonts can be problematic.

Poor results: Blurry scans, photos of printed pages, handwritten documents. The AI struggles with these because the text extraction is unreliable.

Won't work: Password-protected files (remove the password first), corrupted files, DRM-protected documents.

If the RFP or proposal contains important pricing tables or technical matrices in Excel, upload the Excel file directly rather than a PDF export. The system handles tabular data in spreadsheets better than tables rendered in PDF.

File naming

The AI sees file names and uses them for context when searching documents. Descriptive names help:

Common mistakes to avoid

Uploading the RFP as a bid document (or vice versa). The AI treats the RFP as "what's required" and bid documents as "what's offered". Mixing these up produces nonsensical results.

Starting analysis before parsing completes. If documents are still being parsed, the AI works with incomplete information. Always wait for all files to show "Completed" status.

Uploading duplicate files. If the same document appears twice, the AI processes it twice (using more credits) and might raise duplicate findings.

Leaving old versions alongside new ones. If a vendor sent a revised proposal, remove the old version unless you specifically want both analyzed.