Client portals and e-signature: customers sign exactly what the record holds.

One figure from the proposal to the payment.

When the portal reads from your records, the price in the proposal is the price that gets signed, booked and invoiced. Without it, the stretch between handshake and payment runs on copies: a proposal sent as a PDF, a contract printed and scanned, an invoice re-sent because the first went missing, a change request living in a chat thread.

Each copy is a place for the figure to drift, so the portal replaces them with one record and one sign-in.

• Proposals read in the browser.

  Versioned and rendered from the same source as the signed PDF, so the page reviewed and the page signed cannot differ.

• Signature where they read.

  The customer signs in the browser, both sides keep the same file, and the acceptance is written to the record.

• Invoices and payment.

  The signed schedule, the invoices raised against it, and a card payment where you want one.

• Requests that become records.

  Each one arrives in your system as a tracked item with its attachments, ready for someone to act on.

• One sign-in, several companies.

  An owner of more than one company signs in once and switches between them, and no record crosses over.

• An audit trail.

  Who saw what, when, and what they signed.

Every signature is recorded with the evidence behind it.

Under Article 10 of Federal Decree-Law No. 46 of 2021 on Electronic Transactions and Trust Services, the UAE's law onshore, a contract keeps its validity and enforceability when offer and acceptance are made electronically. Article 8 adds that an electronic means which identifies the signer and shows their intention can meet a legal requirement for a signature, on conditions the same article sets.

The law also recognises a stronger form. A Qualified Electronic Signature, made with a qualified certificate from a qualified trust service provider holding a TDRA licence, has the same legal effect as a handwritten one (Articles 18 and 20). The Cabinet may exclude transactions from the law (Article 2), and the DIFC and ADGM have electronic transactions rules of their own.

At the moment of signing, the portal records five things:

• The signer's full legal name and the capacity they sign in.
• An explicit agreement to the scope, amounts and terms.
• A one-time code sent to the signer's email, valid for 10 minutes and usable once.
• A hash of the content the signer reviewed, which must match the current document before a code is issued, so an edit made after they opened the page cannot be signed unseen.
• The signed PDF with its SHA-256 fingerprint, and an audit record of the time, IP address and browser.

Together they make authenticated electronic-signature evidence. It is not a Qualified Electronic Signature, and the record states as much. Where a document needs one, or the law excludes it, we tell you before you rely on the portal. Our guide to electronic signatures in the UAE has the detail, as general information and not legal advice.

A guessed link to another customer's file returns nothing.

Every record route authorises on its own, so a request for somebody else's document finds nothing to return. That follows OWASP, whose Top 10 for 2025 puts broken access control first and advises denying by default and enforcing record ownership.

We apply it at the read. A customer's query fetches that customer's records and nothing more, and a figure a role may not see is left out of the query itself, because data fetched and then hidden has still been sent. Each form that changes something carries a CSRF token. Behind every one of these rules sits a test that was watched failing against the defect it guards.

We run our own client work on this portal. In use

Every SolaryxDev client signs in at portal.solaryxdev.com. There they read proposals, sign contracts, pay invoices, follow project stages and send requests, and our own agreements are signed there too, each copy kept with its signer record.

• Sign-in by a one-time code sent to the client's email.
• One sign-in for a person linked to several companies, with each company's records hidden from the others.
• Proposals render from the same source as the signed PDF.
• Invoices are paid by card, with each checkout opened once per invoice and amount.

It reads from ERPNext, the system that holds our own books, and it is not for sale. For your customers we build the same thing, carrying your name and reading from your records.

• Client login

The build starts from the documents you send today.

1. Document audit.

   Your proposal, contract, invoice and statement as they stand, with the exceptions people make by hand.

2. One source per document.

   Each is rebuilt so the screen and the signed PDF render from one source, and no edit can reach one and miss the other.

3. Roles and access.

   What each role may see, enforced in the query itself.

4. Signature and payment.

   The signing flow, a counter-signature where you need one, and a payment step if money moves through the portal.

5. Pilot with real customers.

   Two or three of them, with the old path open until nobody asks for it.

The number of document types sets most of the timeline, and the signed proposal carries the dates.

The portal holds no figures of its own.

It reads each one from your ERP, through the API on ERPNext and through whatever any other system exposes.

Hosting and the warranty follow the terms on pricing and engagement.